The usual blocker when you win a client from another gateway is not price, it is their code. The sending format is buried in an ERP, a CRM or a script somebody wrote in 2016 and left. API Signatures solves that: you map their parameter names to yours, and the only thing they change is the URL.

Open it from Settings → API Signatures. Access is controlled by the admin role permission category Settings, feature API Signatures.

When this is the right tool

The customer sends username, to, text, from and you expect userid, mobile, msg, senderid.
Their request body is fixed by middleware they cannot change, but they can point the host somewhere else.
You are migrating someone off Flash49, GS Send or a similar gateway and want zero code changes on their side.
A reseller wants an API that looks like the one their customers already use.

Setting one up

Click Add. It is a two step wizard.

Step 1, Basic

Display name: internal label, for example “Flash49 Customer API”.
URL key: the slug in the endpoint path. Lowercase letters, numbers and underscores. It is suggested from the display name and must be unique within its scope.
Customer account: bind it to one user, or pick All users for a shared compatibility endpoint that works for any valid login.
Active: on by default. A disabled signature rejects traffic without losing the config.
Start from template: Blank, Standard SMS, Flash49 or GS Send. Templates pre fill the usual mappings.

Step 2, Parameters

Map each of your system fields to the customer’s parameter name. Login, Password, Mobile and Message are required. You can also map Sender ID, message type, DLT Entity ID, DLT Template ID, DLT Telemarketer ID, campaign reference and response format.

There are transforms for the awkward cases: pass a value through as is, accept unicode=true instead of a message type, handle GS style message type values, normalise format=text to plain, force lowercase, decode HTML entities, and fall back to a default sender when the customer omits one. Show advanced fields covers schedule time, contact group and similar.

The Live URL preview builds a sample query string with placeholder values so you can sanity check the mapping before saving.

The endpoint

The signature endpoint follows this pattern:

https://your-domain/SMSApi/signature/your-url-key

GET and POST both work, with the parameters in the query string or as form body.

Give the customer the full URL. On their side, only the host and path change.

Editing, disabling and deleting

Edit a signature from the list with the pencil icon. You can change mappings whenever you like without touching the customer’s integration, as long as the URL key stays the same. Change the key and you have changed their endpoint, so tell them first.

The power icon enables or disables a signature without losing the mappings, which is what you want during testing or when a customer pauses an old integration. Delete removes it for good.

Cache refresh

After any create, edit, delete or toggle, the platform tries to refresh the signature cache on the API server straight away. If that refresh fails, the change can take around 15 minutes to propagate, or you can restart the API server for immediate effect. There is a Refresh cache button on the list page for forcing a global refresh after bulk changes.

A workflow that avoids surprises

Ask the customer for one real sample request: the URL, the method and every parameter.
Work out which parameters carry login, password, mobile, message, sender and DLT data.
Create the signature from the closest template, then fix what differs.
Test with the live URL preview and a test account, with the signature still disabled if you prefer.
Enable it, confirm the cache refreshed, and watch the message logs for that test user.
Send the customer the endpoint URL and let them switch.

Found this useful?Add as Preferred Source on Google

API Signatures: Let Customers Keep Their Old API Parameter Names