Developer and API Policy

1. Scope

This policy governs programmatic interaction with MessageFuel: the embed snippets we generate for your signup forms, the webhooks that carry delivery events, any automated access to the platform, and any API we make available in future. It is part of the Terms of Use.

2. Embed snippets and the loader script

Each signup form can be embedded three ways: a frame, plain HTML that posts directly, and a small script that injects a frame and keeps it correctly sized. We grant you a licence to place those snippets on websites you own or operate, for the purpose of running that form.

• Do not self-host or modify the loader. Load it from our domain so that fixes reach your site. Copying its contents into your own bundle freezes a version we can no longer patch, and a frozen loader is what turns a routine change into a broken form on someone else’s website.
• The message protocol is versioned by name. The frame and the loader exchange a small number of named messages — one to size the frame, one to report a completed signup. We treat renaming one as a breaking change and will ship a release that accepts both names before retiring the old one. Adding a new message type is not a breaking change. Do not rely on any message we have not documented to you.
• The loader does not fire your marketing tags. It republishes a signup as a data layer event and a DOM event, and stops there. Choosing which conversion event to fire, and configuring it, is yours — firing one ourselves would double-count for anyone who already tracks the submit.
• Do not embed a form in a deceptive context. The page around the form must make clear who is collecting the data, and the consent wording must be accurate. See the Acceptable Use Policy.
• Do not use the embed to collect data other than by voluntary submission, and do not pre-populate a form with contact data harvested elsewhere in order to manufacture a consent record.

3. Webhooks and callbacks

The platform receives callbacks from delivery providers: inbound SMS and delivery receipts from Twilio, and engagement events from SendGrid. Those endpoints are ours, not yours, and they verify a provider signature before accepting anything.

• Do not post fabricated events to them. Forging a delivery receipt or an unsubscribe event is an attempt to corrupt another party’s consent record, and we treat it as such.
• Configure the webhook URLs we give you, unmodified, in your provider account. A callback pointed at a redirecting host silently loses every event that passes through it, and the symptom is a page of confident zeros rather than an error.
• Keep the signing keys and secrets involved confidential, and rotate them if you believe they have been exposed.

4. Automated access

• No scraping or headless automation. Do not script the dashboard, crawl it, or extract data from it other than through the exports we provide.
• Respect rate limits. Do not attempt to exceed a documented limit, run traffic through multiple accounts to evade one, or issue requests at a volume that degrades the Service for others.
• Identify yourself. Any permitted automated client must send an honest user agent that identifies the application and a contact address.
• No load or penetration testing without permission. Ask first, in writing, and agree a window with us.
• Stay inside your own tenancy. Do not attempt to reach data belonging to another organisation, enumerate identifiers, or probe tenancy boundaries.

5. Credentials and tokens

Credentials issued to you — account passwords, provider API keys stored in your settings, your MessageFuel API keys, and the signing secrets we generate for your webhook endpoints — are confidential and are for your organisation only. Do not share them, commit them to a repository, or embed them in client-side code, a mobile app or anything a browser can read.

An API key is shown once, when it is created. We store a cryptographic hash of it and cannot recover the key itself, so a lost key is replaced rather than retrieved. The API deliberately accepts no cross-origin browser request, because a key that works from a web page is a key every visitor to that page can read.

You are responsible for activity performed with your credentials. Tell us immediately at Info@messagefuel.com if you believe one has been exposed, and rotate it at the provider.

6. Consent over the API

Writing contacts programmatically does not change who you may contact, and the API is built so that it cannot. It is able to close a channel and never to reopen one.

• Consent cannot be granted through the API. Fields describing opt-out or suppression state are ignored on a write, and the response tells you which were ignored. Somebody who opted out stays opted out until they resubscribe themselves, through a preference centre link or a fresh signup. This holds even if your own system believes otherwise.
• Creating contacts requires an attestation. A request that would create somebody must state that those people agreed to be contacted. We record it against the key that made it, and it is the record we would rely on if a complaint were ever made about that contact.
• A bounce is not an opt-out. When you record a withdrawal you tell us which you mean. An undeliverable address is a delivery fact and can be cleared later; an opt-out is a person’s instruction and cannot. Systems that file both under one flag are common, and importing that conflation would permanently close a channel over a full mailbox.
• Ticketing integrations send the checkout’s own consent. A ticketing platform sends every order, but a buyer joins your list only for the channels they agreed to at checkout, and each opt-in must carry the method and the exact wording the buyer was shown. An opt-in ticked on a staff device at a box office is confirmed by the buyer replying YES before their number is used. You are responsible for that wording being accurate and for the checkbox being unticked by default.

7. Data you retrieve

Data you export or receive through any integration is still Customer Data and still personal data. Everything in the Terms of Use, the Acceptable Use Policy and the Data Processing Addendum continues to apply to it once it is in your systems — including consent, suppression and retention. Moving a contact into another tool does not reset their opt-out, and an export is not a licence to message people who told you to stop.

8. Security research and responsible disclosure

We welcome reports from security researchers. If you find a vulnerability, tell us at Info@messagefuel.com with enough detail to reproduce it, and give us a reasonable opportunity to fix it before disclosing it publicly.

What we ask

• Use only accounts and data you own or have permission to test. Do not access, modify, exfiltrate or retain another customer’s data — if you encounter it, stop, and tell us what you saw.
• Do not degrade the Service: no denial of service, no volumetric testing, no spam or unsolicited messages sent through it, and no social engineering of our staff, customers or providers.
• Do not use a finding to send messages to anyone.

What we commit to

We will acknowledge your report, keep you updated, and credit you if you want credit. Research conducted in good faith and within the boundaries above is authorised: we will not pursue legal action over it, and we will say so if a third party asks. We do not currently run a paid bounty programme.

9. Changes, deprecation and enforcement

Anything we document as an integration surface — the embed snippets and their message names, and any API we publish — we will change carefully: additive changes at any time, and a deprecation window with notice to affected account holders before anything is removed or renamed. Undocumented internal endpoints carry no such commitment.

We may throttle, suspend or revoke programmatic access that breaches this policy, threatens the stability or security of the Service, or is used in a way we did not authorise — immediately where the risk requires it.

Contact