For many tide apps, the simplest integration is also a practical one: request predictions directly from the app when a user needs them, then cache the results for that user. A backend can add useful control, but it also adds infrastructure and another service to maintain. The right choice depends on what your product needs, the permissions attached to its API key, and the consequences of misuse.
Many WorldTides customers use a shared API key in their apps. In our experience supporting these integrations, reported misuse has been uncommon. That experience makes direct access worth considering rather than automatically ruling it out because a key could be extracted.
Two ways to connect
With a client approach, a mobile or desktop app sends an HTTPS request directly to WorldTides and receives predictions to display or cache for its user.
With a server approach, the app sends a request to your backend. Your backend calls WorldTides and returns the result to the app. The WorldTides key stays on your server.
At a glance: why start with client requests?
For an app that primarily needs to display tide predictions, direct client requests are our recommended starting point. They deliver the same WorldTides data with less infrastructure to build and operate. A backend becomes useful when you need the additional controls it provides.
| Consideration | Recommended starting pointClient sideSimpler setup · Less infrastructure | Server sideAdditional control · More infrastructure |
|---|---|---|
| Getting started | Fewer components: connect the app directly to WorldTides | Build or extend a backend endpoint as well as the app |
| Hosting costs | No prediction-proxy hosting or bandwidth bill | Your backend carries both the request and the response |
| Growing your audience | No proxy capacity to expand as prediction traffic grows | Monitor and provision backend capacity for peak demand |
| Request path | One service connection: app → WorldTides | Two service connections: app → your server → WorldTides |
| Backend outages | Tide requests can continue independently of your backend, unless needed for login or key retrieval | New predictions depend on your backend being available |
| Maintenance | Less infrastructure: no prediction proxy to deploy, patch, or monitor | Maintain the proxy and its hosting environment |
| Offline viewing | Cache on the device for the requesting user | Also possible, but the app still needs its own local cache |
| Key replacement | Remote configuration is an option: distribute a replacement key without proxying predictions | Change the WorldTides key centrally on your server |
| API-key exposure | Shared key can be extracted; monitor credits and plan for rotation | WorldTides key stays on your server; protect the proxy against unauthorized use |
| Per-user enforcement | App can manage its user experience; a shared key does not enforce individual entitlements at the API | Backend can enforce authentication, entitlements, and per-user request limits |
| API credit costs | Same charge for the same request; cache results for the requesting user | Same charge for the same request; server caching does not grant cross-user sharing rights |
| Best fit | Straightforward tide features with minimal operating overhead | Products that need central enforcement or server-side processing |
Either approach can scale. Direct requests avoid making your backend carry prediction traffic. A well-designed backend can also handle large audiences, but capacity, operating cost, and availability become your responsibility.
Why direct requests often make sense
Direct access keeps the integration small. Your app requests the location and dates its user needs, receives the response, and displays the result. You do not need to build a prediction-distribution service before launching a tide feature.
It also removes your backend from the prediction request path. If your backend is unavailable, direct tide requests can still work, provided the app does not need that backend to sign in or obtain its key first. Already cached predictions can remain available without a new network request.
Usage follows demand. There is no need to retrieve predictions for hundreds of stations every morning just because some users might visit them. Ask for data when it is needed and reuse the results for the same user when they cover the requested location and time period.
Put API-key exposure in context
A shared key distributed with an app can be extracted. Moving that same key into remote configuration does not make it impossible to obtain. The engineering question is what someone can do with it and whether the added controls justify the complexity.
A WorldTides API key authorizes requests against your account's API allowance. Treat that exposure according to its scope rather than automatically equating it with a payment credential or a key granting administrative access to your own systems.
For a credit-limited account, unauthorized requests can consume available credits. A usage spike can exhaust the balance and interrupt legitimate users. The key's usefulness is constrained by the account's available allowance; it is not an unlimited resource. Renewals and additional purchases can replenish that allowance, so monitoring still matters.
Our experience is that this type of misuse has been uncommon. That supports a proportionate response: understand normal usage, watch for unusual increases, and have a recovery plan. It does not require every app to run a proxy solely to keep a tide API key out of its package.
If you suspect misuse, contact WorldTides support. Depending on the traffic, we may be able to contain an incident using IP addresses, user-agent patterns, or request parameters while you distribute an update. These are targeted measures: addresses can change, and user-agent values can be copied. They do not replace key rotation when it is needed.
Add control without proxying every prediction
You can keep direct prediction requests while adding a small amount of server involvement:
- Retrieve the current key from your server. The app obtains it at startup or during configuration refresh, then contacts WorldTides directly. You can change the distributed key without waiting for every user to install a new build.
- Notify the app when its key changes. A push notification can prompt the app to retrieve updated configuration over an authenticated HTTPS connection. Refresh at startup or after an authentication failure as well, since notifications may not arrive.
- Require authentication before releasing a key. Your server can check the user's entitlement before supplying configuration. Once a shared key reaches the device, however, it can still be copied; key distribution alone does not enforce entitlement on every prediction request.
These are patterns you implement in your own app and backend, not automatic WorldTides key-distribution features. WorldTides lets you reset the API key in your account settings. Existing clients using the old key will need the replacement, so plan how they recover before rotating it. See the API documentation.
When a backend earns its place
A backend is useful when you need central authentication, per-user request limits, subscription enforcement, or integration with other services. It can validate allowed locations, forecast ranges, and request types before calling WorldTides. It also keeps the WorldTides key off user devices and gives you a central place to change request logic.
Those benefits require an actual access-control layer. A publicly accessible proxy that accepts arbitrary requests can still be abused and consume your credits. Authenticate callers and constrain requests if those are the reasons for choosing a backend.
Keep architecture, licensing, and credits separate
Routing requests through your server does not change the licence. Under the standard per-user model, predictions are retrieved on behalf of an individual user and may be cached and redisplayed to that user. Storing one prediction on a server does not automatically grant permission to distribute it across your customer base. The station list has a separate sharing allowance. See the developer licensing guidance and WorldTides terms.
Credits depend on the request, rather than whether it originates from a device or your server. At standard sampling, up to seven days of heights costs one credit, and up to seven days of extremes costs another. Fetching one day instead of seven generally does not save credits for those data types. Avoiding unnecessary repeat requests does. Check the credit calculator for your parameters.
For example, 1,000 users each making one seven-day heights-and-extremes request per week would consume approximately 8,700 credits per month, using 52 weeks divided by 12 months. That is a planning example, not a claim about every app's usage. More locations and requests increase consumption; repeat views of the same user's cached data need no new API call.
Cache by the relevant location, dates, datum, and request settings. Preserve the required attribution, and handle errors without retrying indefinitely. Astronomical predictions do not need to be refreshed like live weather observations, but source data and models can be corrected; do not assume results can never change. WorldTides is not for navigation or safety-critical use. The terms explain the applicable restrictions.
Choose the smallest integration that meets your needs
Start with direct client requests when your app needs straightforward tide predictions and you are comfortable with the bounded exposure of a shared usage key. Add remote key configuration if easier rotation would be valuable. Use a backend proxy when central enforcement or other product requirements make it worthwhile.
The aim is reliable tide access with operating costs and controls appropriate to your app. A server can be a useful tool, but it does not need to be the default answer to every API-key concern.
