Best Practices

Some Best Practices to keep in mind when implementing your endpoint.

Only subscribe to the events that are needed

You should use the event filter of the Data Connector to only forward the event types you need. This will reduce the amount of work your server needs to do. See the Configuring a Data Connector page for more information.

Respond within 10 seconds

Your endpoint should complete its work and respond with a status code in the 2xx range within 10 seconds. If your endpoint takes much longer than this, it will be considered a failed delivery and will be retried according to the Retry Policy

If you think there's a possibility that your processing might take more than 10 seconds, prefer to write the event to a separate queue or a database and do the processing at a later point in time.

Use the eventId for deduplication

Your endpoint should be prepared to handle duplicate deliveries. While rare, in some scenarios, DT Cloud will forward the same event two or more times through a Data Connector. This can happen in scenarios such as network errors, timeouts, or other things where DT Cloud is not certain that the event has been correctly forwarded to your endpoint. This behavior is what provides an at-least-once guarantee for Data Connectors.

In order to make sure your endpoint is ready to handle these duplicate events, you should check the event.eventId field and check if it's an event you've already processed.

In the event that a duplicate event is sent, it will often be sent within a few seconds of the original event. However, we can not provide any guarantees about the timing of these duplicates.

Use valid SSL certificate issued by a well-known CA

DT Cloud will always verify the SSL certificates of a URL before delivering events to it. The SSL certificate needs to be issued by one of the Certificate Authorities in Mozilla's CA Certificate Program. See the Server Configuration section for more information.

Check the event type before processing the event

Before you start decoding the event.data field of an event, you should make sure that the event you're processing is one of the expected event types by checking the event.eventType field. You should do this even if you're only subscribing to one event type. This way, your integration will not break or throw unexpected errors if you ever start subscribing to different event types, or if a new event type is added to the API.

Disable Data Connector while not in use

If you don't need a Data Connector for some time (for example if you're done with some testing), it's a good practice to disable it and then re-enable it when you need it again. This is because DT Cloud will automatically disable a Data Connector if it has had errors continuously for an extended time period (it will be set to the state SYSTEM_DISABLED). Disabling it yourself instead will give you more control over when this disabling happens, so you will not be caught by surprise that it's been disabled.

See more in the Auto-Disabling of Data Connectors section for more information.