Skip to main content
wede provides official SDKs for five platforms. They add the offline layer to your applications. Operations captured without connectivity stay on the device and are synchronised automatically when the connection returns. Field teams receive messages and reply when there is no data connection. Devices are registered with the platform and removed from it.

Field teams’ replies by SMS

When there is no data connection, a field team receives its messages by SMS (a mission, or a request for its status) and replies by SMS. The SDK opens the message on the device. When the team member taps a status in your app (available, on route, on site, completed), the SDK composes the reply and, from version 2.8.0, sends it for you. The SDK keeps the number the device replies to. Ask for it once with network, after the device’s phone number is active, and the SDK uses it with no network afterwards. An answer to a status request or a mission is one SMS.
How the reply leaves the phone depends on the platform, not on wede: The number comes from GET /v1/devices/{device_id}/sms-reply. When there is none, the reason comes with it: the device has no active phone number, the organisation has no SMS channel, or its SMS go out under a sender name, which cannot be replied to. The SMS permission on Android (SEND_SMS) belongs to your app, never to the SDK. The wede SDKs do not declare it, so adding them never adds it to your app. Google Play accepts an app that sends SMS directly only when it is the default SMS app or falls within one of the exceptions of its policy on SMS and Call Log permissions, for example emergency alerts or SMS-based financial transactions, after a permissions declaration and review. The exception for enterprise apps does not include sending SMS. Check whether your app qualifies before you plan on replies with no tap. If your app reaches phones another way, privately or through your device management, confirm with that channel which rules apply. Plan on one tap per reply as the normal case.

Every device accounts for what it captured

From version 2.5.0, every operation a device captures with no network carries the identity of that device and its place in the device’s own numbering, sealed on the device before it is sent. When the operations reach wede, the Devices page shows for that phone, tablet or terminal what arrived, what is still missing and whether its record is intact, exactly as for any other machine. A device registers itself with wede before it sends its first operations, so every operation is attributed to it from the start. Nothing changes in your code: update the SDK and keep capturing as before. Applications on earlier versions keep working.

Your books, from your server

From version 2.6.0, every SDK reads the operation ledger and works with reconciliation: your server sends its own records (a bank statement, an ATM journal, a terminal counter) in batches of any size and gets the outcome of each one, matched, differs, unmatched or already received. See Operation types and the ledger and Reconciliation. Sending records belongs on a server with the API key; an app of a signed-in user can read the results when its role sees reconciliation. From version 2.7.0, every SDK also records what your organisation decided about an operation or a record that did not reconcile, one at a time or any number in one call (500 per request, in order, one result per decision), reads the history of decisions, closes each day of a source with your own totals and reads the closings, and reads each device with what it sent. See Your decisions and Closing each day.

How to get access

1

Agreement

Your organisation signs an agreement with wede (contract, NDA or MOU) that includes access to the SDKs.
2

Access enabled

wede enables access for your organisation.
3

Download

Company admins and technical users open Downloads in the wede dashboard, accept the SDK terms of use and download the SDK for their platform, with installation instructions.
4

Updates

New versions appear in Downloads, and company admins are notified by email.

How the SDKs are protected

Each download is a unique copy for your organisation, delivered compiled and without source code. Copies identify themselves to the wede API, and wede can revoke a copy used outside the agreement. Downloads are open while the agreement and the annual licence are in force. Copies already in use keep working unless they are revoked.

Credentials

  • On a server, use a tenant API key (wede_live_... or wede_test_...) and keep it secret.
  • In a mobile app or a browser, sign the user in and use the session token. Never ship an API key in an app: anyone can extract it. The API accepts cross-origin requests from any origin (it authenticates only by headers, never by cookies), so a web app can use the session token directly.
A session token lasts 8 hours. Sign in again and give the SDK the new token. Five failed sign-in attempts lock the account for 15 minutes. What a session token can call depends on the user’s role. For example, sending events online needs company_admin, company_tech or corporate_client, while every tenant role can sync operations captured offline. A call outside the role returns 403. See Authentication.

Without an SDK

Server-to-server integrations can call the REST API directly with an API key. See the API reference.