On Ignition 8.3 you create a Standard tag provider outside the web UI through the gateway HTTP API, with a POST to /data/api/v1/resources/ignition/tag-provider. A 403 on that route for an account that is a full gateway admin means one thing: the request authenticated with a username and password. The API accepts tokens only.
Drop the fixes that keep failing
Engineers usually try these first. Each one wastes an afternoon.
- Searching the Java SDK for a Standard provider factory. Module code has long been able to register a managed tag provider, but not a standard realtime provider identical to one built under Config. The 8.3 documentation adds no dedicated SDK method for it. Stop searching. The creation path is the config resource API.
- Substituting a managed provider. It registers, but it is a different kind of object. Your module owns it and controls its lifecycle, and it does not appear as a gateway-configured Standard provider. If the requirement says "identical to the Config entry", a managed provider does not meet it.
-
curl with
-u username. Run with-vand you see a correct Base64Authorizationheader. The user is an admin, and the response is still403. The credentials are fine. The auth scheme is wrong. - Adding roles to the user. This changes nothing. The route never evaluates the user's identity.
-
Issuing an HTTP GET from the module
GatewayHook. This returns503, which is a separate problem covered below. Even after you fix it, the call still needs a token.
Why an admin account gets 403 on the tag-provider route
The 8.3 HTTP API is built for machine-to-machine access. External systems authenticate with API tokens, not interactive user logins. The gateway ignores a Basic Authorization header, so it treats the request as having no valid credential. The request reaches the route, so you get 403 Forbidden rather than a connection error.
Rule out the network first. A 403 proves the gateway is listening on 8088, the path resolved, and the web server is up. Do not chase firewalls or ports.
| Symptom | Cause | First action |
|---|---|---|
403 with -u admin credentials |
Basic auth sent; API expects a token | Create an API key and send its token |
403 with a token on POST, 200 on GET
|
Key's security levels cover read but not write permissions | Check the gateway's API read/write permission settings against the key |
503 from inside GatewayHook
|
Web layer not ready to serve the route when the module calls it (typically during startup) | Defer the call until the gateway is fully running |
404 on the find route |
Provider name misspelled or wrong case in the path | Copy the exact name from the provider list |
400-class error on POST
|
Hand-built body does not match the resource schema | Clone the JSON from an existing provider |
Create an API token and prove read access first
Confirm authentication with a read before you attempt any write.
- Open
http://localhost:8088/openapion the gateway. The spec is generated dynamically from the gateway and its installed modules, so it matches your exact version. Read the security scheme section to get the token header name. The API Documentation page of the Ignition User Manual covers the same material. - Create an API key in the gateway's security configuration. Copy the token as soon as the gateway displays it, and store it like a password.
- Check the security levels attached to the key against the gateway's API access and write permission settings. A key that only satisfies read access passes every
GETand fails everyPOSTwith403. - Test with a read against a provider you know exists:
Replace default with any existing Standard provider name. A 200 response with a JSON body means authentication is solved. A 403 at this step means the token or header name is wrong. Do not move on until this read returns 200.
Clone a Standard provider through the tag-provider endpoint
Do not write the POST body from scratch. The gateway already holds a valid Standard provider document, so start from that.
- Save the
GETresponse from the previous step to a file, for exampleprovider.json. - Open the
POSToperation for/data/api/v1/resources/ignition/tag-providerin/openapi. Compare its request schema with the saved JSON. - Change the name to the new provider name. Remove any fields the schema marks as read-only or server-generated. Leave the provider type and settings unchanged so the new provider comes out as a Standard provider.
- Send the edited document:
- If the response is a
400-class error, read the body. The gateway names the field that failed validation. Fix that field only and resend.
The same pattern works for database connections. Find the matching resource type in /openapi, GET an existing connection, edit it, and POST it back.
Fix the 503 from inside the module GatewayHook
A 503 Service Unavailable means something answered, but the service behind the route was not ready. The usual cause is calling the gateway's own API from startup() in the hook. At that point the gateway is still bringing up modules and web routes, and your module is part of that startup sequence.
- Move the call out of the synchronous startup path. Run it on a background task after the gateway finishes starting, with a bounded retry and backoff on
503. - Add the token header to the in-module request. A loopback call does not get implicit trust. Without the token it fails with
403once the503is gone. - Store the token in your module's configuration. Do not compile it into the module.
- Consider whether you need HTTP at all. The route path shows the call writes a config resource of type
ignition/tag-provider. Check the 8.3 SDK javadocs for the gateway's configuration resource interfaces before you build an HTTP client into a module to talk to its own host.
Confirm the new provider exists and survives a restart
- Run the find route against the new name:
/data/api/v1/resources/find/ignition/tag-provider/<newName>. A200response is expected. - Open the tag provider list in the gateway web UI. The new entry should show as a Standard provider with a running status.
- Open the Designer tag browser, confirm the provider appears, and create a memory tag in it. Write a value and read it back.
- Restart the gateway. Confirm the provider and the test tag are still there. A provider that disappears after a restart was registered at runtime, not saved as configuration.
Watch for these recurring traps:
- Forced HTTPS. If the gateway redirects HTTP to HTTPS, curl against port 8088 can follow the redirect and drop your header. Call the HTTPS endpoint directly.
-
Name collisions. A
POSTwith an existing provider name fails or conflicts. Check the name with the find route before you create. - Tokens in shell history. Load the token from an environment variable, not a literal on the command line.
FAQ
Why does the Ignition 8.3 API return 403 for an admin user?
The HTTP API authenticates with API tokens, not usernames and passwords. A Basic Authorization header from curl -u is ignored, whatever the user's roles. Create an API key, send its token in the header named in /openapi, and confirm the key's security levels satisfy the gateway's API read and write permissions.
Why does an HTTP call from my Ignition module GatewayHook return 503?
The call runs while the gateway is still starting, so the route is not being served yet. Move it to a background task that runs after startup, retry on 503 with backoff, and include the API token.
Why does the Ignition Java SDK only let me create a managed tag provider?
The SDK exposes managed providers for module-owned tags. It has no dedicated method that builds a Standard provider identical to the Config entry. On 8.3, POST a Standard provider document to /data/api/v1/resources/ignition/tag-provider instead, starting from JSON cloned from an existing provider.
Escalate to Inductive Automation support in two cases. The first is a valid token that passes GET but still gets 403 on POST after you have checked the write permissions. The second is a cloned body the gateway rejects without naming a field. Include the gateway version, the exact request, and the full response body from curl -v.