- Messages that are submitted to Flowmailer will be confirmed by a 201 Created response. Only when this response is received, a source system should assume the message will be handled by Flowmailer.
- In any system integration, eventually individual calls will fail. To prevent loss of messages, a retry mechanism, preferably backed by a queue system, is required.
- The Flowmailer REST API can be reached by multiple IP addresses. Retries should be done to different IP addresses to maximize availability.
- Always use HTTPs connections and check the validity of the offered certificate.
- Use separate credentials for different source systems and instances. Also make sure these credentials have their minimum required role assigned; i.e. you don't need Admin privileges to submit messages.
- Your client should accept any valid certificate if a trustworthy chain can be established. Please do not register the current certificate in use, to prevent problems when it's replaced.
- Our service IP addresses change rarely, however, please connect using our DNS names and configure your environment to adhere to DNS record changes.
- Authentication tokens are valid for multiple requests. Please use them for as long as they're valid, especially in batch processes.
- Utilize HTTP keepalive, sending multiple requests using a single connection. Establishing HTTPs connections is relatively slow and should be avoided.
- Enable HTTP Pipelining if possible.
- If you need more performance and eliminate the effects of latency, please feel free to connect up to 10 times concurrently, especially when submitting messages.
- Avoid unnecessary load, for instance by requesting the same reports repeatedly with large overlapping dateranges.
- Engineer the whole of your processes in an efficient way. For instance, if you want to receive all events for all messages, you should use the message_events call instead of, for instance, repeatedly requesting the status for each message.
More information about REST API