Passive Marketplace or White-label App Platform Integration Module

Introduction

Connect your marketplace or restaurant white-label app to Sinqro (asking Sinqro to consume your APIs and throwing webhooks to Sinqro)

Passive integration

This guide is ONLY for passive integrations, understood as integrations in which Sinqro will consume your API services and listen your webhooks.

If you don't have your own API and webhook notifications and you are not planning to develop them, please go to market active integration docs.

Integration level

In Sinqro we have different integration module types.
For a market integration module, we have different module features in order to help the restaurant to understand the benefits of contracting the module.

All features are optional and defined by the limits of the company developing the integration and the company providing API or services webhook.
As this guide is for passive integrations, your API and webhooks notifications will define the features of your platform's module, because Sinqro will always integrate as many features as your platform allows.

Integration requirements

For a full integration, we would need all these API services and webhooks, but as explained before, we'll adapt the integration to what you already have working or you have decided to implement for us:

API SERVICES
  • GET Order / Reservation
    Service/s to get an order or reservation information of a previously received order
  • GET Order / Reservation Status
    Service/s to get an order or reservation status of a previously received order
  • POST/PATCH Menus, menu sections, products, product variants, product option categories and product options
    Service/s to create or modify a single entity or a collection of the entities defining the "online catalog" of the restaurant
  • POST/PATCH Order / Reservation Status
    Service/s to change the status of a previously received order or reservation
  • POST/PATCH Delivery Location (for delivery orders)
    Service/s to inform the current driver's location(for you to show it to your customer)
  • POST/PATCH Restaurant Availability
    Service/s to change the restaurant's availability in your market (schedules, shifts, calendar exceptions, ...)
WEBHOOK NOTIFICATIONS

The webhook notifications are POST/PUT requests thrown by your system to a specific endpoint we provide.

  • New order / reservation WEBHOOK
    Notification you send for a new order or reservation
  • Order / reservation status changed WEBHOOK
    Notification you send for an order or reservation status change from your side

We will provide two endpoints to receive your notifications. Example:
SANDBOX: https://sandbox-integrations.sinqro.com/{your-pos-code}/webhooks/{any-other-data}
PRODUCTION: https://integrations.sinqro.com/{your-pos-code}/webhooks/{any-other-data}

OTHER REQUIREMENTS
  • API and webhooks docs
    Document or whatever you normally use you document your API for third-party developers
  • Restaurant test account
    An account to test and ideally access to the restaurant's dashboard (as the restaurant user normally does)
  • Sandbox (test) and production environments credentials
    API keys or equivalent for production environment, and ideally, for sandbox/test environments

Data model

As this integration is passive, we adapt our data to your data model (to consume API services and understand the webhooks).

Despite this, in some cases we are asked to help you (developers) providing examples of what Sinqro understand as order, reservation, menu, menu section, product, productVariant, productOptionCategory or productOption, because maybe, you'd like to improve one of your existing services or create new ones.

In order to show you examples of these entities, and only for this purpose, we invite you to check the market active integration docs.

Integration request

If you already have your API and webhooks docs and you want Sinqro to develop the integration module, please send us an email to integrations@sinqro.com

Integration validation

We’ll provide a document explaining which features have been integrated and which ones were not integrated and the reasons, and of course, we’ll attend any validation session if it’s considered in your workflow.