Integration guidelines (must read)

When building integrations to Agillic please follow these guidelines:

  • Restrict your data upload to what is needed for personalisation of communication to be sent from Agillic.
  • Architect your solution for robustness. Implement retry policies to contain the problem, should Agillic provide backpressure if the limit on concurrent calls is breached or be temporarily unavailable due to network issues between the systems or during system updates.
  • The Agillic public API supports 20 concurrent API calls (see the API documentation for further requirements). Consider a connection pool to avoid protocol overhead.
  • If it is not possible to restrict the number of concurrent calls, e.g. there are many different systems calling the Agillic public API, you can rely on the backpressure mechanism to throttle the API requests and ensure fast response times.
  • Consider if API (single, batch, or async), webhook, ETL, or file transfer is optimal for your integration. You are welcome to consult us on this.
  • Follow our best practices e.g. don’t exceed 100 rows per recipient in OTM tables or 1 million rows in Global Data Tables.
  • Use OAuth 2.0 for authentication if possible.
  • Ask for guidance. It may just save you (and us) lots of work.
  • Uploading recipient data to Agillic from a CDP, CRM, POS, websites etc.
  • Triggering a send out of receipts and other transactional communication
  • Exporting activity data for further analytics, scoring, or other use.
  • Using Agillic for logins, tickets, or voucher authentication.
  • Data requests without retry, fallback, and failover handling.
  • API calls without throttling and retry handling.
  • Expose Agillic public APIs to indirect traffic from public websites or apps without taking the limit on concurrent calls into account and without designing for backpressure.