Build on Brudcast

Brudcast has three integration surfaces. The platform API manages everything in your organization. The email send API and the SMTP relay deliver individual emails from your own application. Most integrations use the platform API plus one of the two sending surfaces.

​

The three surfaces

Each credential belongs to one organization, so you never pass an organization ID. See Authentication for how each one is sent.

​

Which one to use

​

What’s the same everywhere

• JSON over HTTPS. Both APIs take and return JSON. Call them from your server with any HTTP client.
• Versioned paths. Both APIs carry the version in the path: /api/v1. See Versioning below.
• Two envelopes. Platform API responses carry success, message, data and sometimes meta. The email send API carries status, message and data. See Response format.
• Accepted is not delivered. A successful send means Brudcast queued the message. Delivery to the receiving mail server comes later, and you learn about it from the message log or a webhook.

​

Versioning

The version sits in the path, and v1 is the only version there is. There’s no version header to send. Change the path, and you change the version. The SMTP relay isn’t versioned, because it speaks standard SMTP. Two API key scopes have been renamed: email:send is now messages:send, and email:read is now messages:read. Keys created with the old names keep working, because Brudcast reads email:send as messages:send and email:read as messages:read wherever it checks a scope. Use the current names in anything new, including your own code that checks a key’s scopes. See API keys. To keep your client working as the API grows, ignore response fields you don’t recognize, treat an unfamiliar status value as unknown rather than as an error, and branch on code and the HTTP status rather than on message text.