Skip to main content

Scenarios

Choose the application type that best matches the system you are connecting to Otter. Each scenario combines the existing domain guides into an end-to-end implementation roadmap and a certification-readiness checklist.

These checklists describe the baseline supported by the current Otter API documentation. Confirm final certification requirements and submission timing with your Otter representative before you submit.

Choose your application type​

Application typeUse this whenMain implementation paths
Online food ordering (OFO)Your marketplace or ordering channel sends orders into Otter and receives menu and storefront changesOrders into Otter, Menus, Storefront
Point of sale (POS)Your POS receives orders from Otter and is the source of truth for menusOrders into your system, Menus Manager
Third-party logistics (3PL)Your delivery network quotes, accepts, and fulfills delivery jobsDelivery quotes, creation, updates, and cancellation

If your product spans more than one type, complete every applicable roadmap. Use the Integrations guides for capabilities outside these three baseline scenarios.

Shared readiness baseline​

Complete these steps before the type-specific roadmap:

  1. Register your application and store its Application ID and client secret securely. Start with Quickstart.
  2. Request only the OAuth scopes your application needs and obtain access tokens as described in Authentication.
  3. Connect your application to at least one existing Otter store as described below.
  4. Register a public HTTPS webhook endpoint, validate every webhook signature, and acknowledge accepted events with a successful response.
  5. Process webhook work asynchronously, make handlers safe for duplicate delivery, and retain enough context to retry failed work. See Events and webhooks.
  6. Respect rate limits and use backoff for retryable API failures.

Connect to an existing store​

Otter creates and manages restaurant stores. An external integration does not create an Otter store; it connects its application and external store id to a store that already exists in Otter.

Complete this connection before starting the OFO or POS roadmap:

  1. Follow Stores and connections to choose the appropriate account-pairing path.
  2. When Otter sends Upsert Store (stores.upsert), validate the existing store and accept the connection.
  3. Use POST /v1/stores to register your external store id for that connection. This operation completes the mapping; it does not create the restaurant store.
  4. Preserve the Otter-to-external store mapping so store-scoped API calls, orders, menus, and webhooks resolve to the same location.
  5. When Otter sends Remove Store (stores.remove), remove the local connection without deleting the store in your system.

The connection is ready when:

  • A store-scoped API call accepts the connected store id in X-Store-Id.
  • OFO traffic resolves to the same external store used for the connection.
  • POS order and menu traffic resolve to the same POS location.
  • Repeated upsert events update the existing mapping instead of creating duplicate connections.
  • A remove event clears the connection without deleting either system's store record.

Reliability expectations​

  • Keep credentials, hosts, stores, and webhook secrets aligned with the application you are testing.
  • Correlate each API request, webhook, callback, and asynchronous job in your logs.
  • Treat duplicate events and repeated callbacks as expected delivery behavior.
  • Distinguish retryable transport failures from payload or business-rule failures.
  • Preserve the original event and the result of each processing attempt for troubleshooting.
  • Test both successful and failed paths before requesting certification.

Evidence to collect​

Prepare a compact evidence package for your Otter representative:

  • Application and store identifiers used for the test.
  • Request ids, webhook ids, delivery references, order ids, and menu job ids that identify each tested flow.
  • Successful API responses and callback results for the primary path.
  • Logs showing webhook signature validation and prompt acknowledgement.
  • Evidence that duplicate delivery and retryable failures do not create duplicate business actions.
  • Expected error responses and the corrective or retry behavior your application performed.
  • Final order, menu job, storefront, or delivery state for every required scenario.

Do not include client secrets, access tokens, webhook secrets, or customer personal data in the evidence package.

Submit for certification​

Review the checklist in your application-type guide, resolve any failed test case, and share the evidence package with your Otter representative. Your representative will confirm the current certification scope, any product-specific exceptions, and the submission process.

Next​