Skip to main content
Business organizations and locations are the resources you use to identify restaurants in the Chataigne API.

Business organizations

An organization represents a restaurant group or business. It has its own ID and name and can contain multiple locations. Use a business organization when an integration needs to work across a group—for example, to discover every restaurant, aggregate analytics, or create a new location.

Update an organization profile

Call PATCH /v1/organizations/{organization_id} with businessOrganization.update. Send name and/or image_url; omitted fields keep their current value. image_url must be a publicly reachable JPG, PNG, or WebP image no larger than 5 MB. Chataigne imports the image and returns its managed URL in the resource. There is no way to clear an existing picture — sending image_url: null is rejected with 400 INVALID_IMAGE_URL, so omit the field to keep the current one.

Locations

A location represents one restaurant. Its profile includes information such as its name, currency, country, timezone, language, contact information, and address. Operational settings belong to the location as separate resources.
organization_id is null for a standalone location.

How access flows

A business-organization-scoped key can access its organization and child locations, subject to its permissions. Access flows downward to locations, never upward from a location to its parent organization. A location-scoped key can access only its location. It cannot retrieve a parent organization or sibling location, even when the location belongs to a group.

Scope does not grant actions

Scope and permissions are evaluated together. For example, a business-organization-scoped key with location.read can list child locations but cannot update one without location.update. A location-scoped key with location.update can update its one location but no other location. See API keys and permissions for the complete permission list.

Resource IDs

Resource IDs are opaque strings. You should:
  • Read IDs from API responses.
  • Store them with your integration’s records.
  • Pass them unchanged in endpoint paths.
  • Avoid parsing them or assuming their length or internal structure.
Use Find your resources to discover the IDs available to your key.