API Authentication
Secure app integrations with the credential patterns already implemented in Indexed PIM: per-app API secrets, webhook signature verification, inbound webhook secrets, and optional bearer-token protection for feeds.
API Credentials
How authentication works in the current app
Authentication in this repository is integration-specific. Different apps store the credentials they need to talk to their remote service, and controllers validate secrets or bearer tokens where inbound requests are accepted.
For example, the WooCommerce app stores a shop URL, consumer key, and consumer secret. The e-conomic app stores an app secret token and agreement grant token. Feed endpoints can require an `Authorization: Bearer ...` header before generating output.
I did not find a generic platform-wide API key manager or OAuth2 layer behind this feature slug, so this page documents the authentication mechanisms that are actually implemented in the app modules today.
Implemented patterns
Per-app outbound API credentials for connected services
Generated webhook secrets and HMAC SHA256 signatures for outbound webhooks
Inbound webhook secret validation on routes such as the e-conomic webhook controllers
Optional bearer-token enforcement for public feed endpoints
Connection testing to verify stored credentials before sync runs
Authentication methods already in use
The app uses practical, service-specific auth instead of one universal credential model.
App-to-service credentials
Integration apps store the remote credentials needed to connect to each service. Examples in the codebase include WooCommerce consumer keys and e-conomic token pairs.
Solution:
Each app instance can be configured independently per market, store, or external account.
Outbound webhook signing
When Indexed PIM sends webhooks, the payload is signed with a generated secret and delivered with an `X-Webhook-Signature` header using HMAC SHA256.
Solution:
Receivers can verify the payload before acting on it.
Inbound webhook secrets
Webhook endpoints such as the e-conomic handlers validate the secret passed to the route before processing updates for customers, products, or booked invoices.
Solution:
Unauthorized callbacks are rejected before the sync handler runs.
Bearer-token protected feeds
The public feed controller can read the `Authorization` header, extract a bearer token, and reject requests that do not match the feed configuration.
Solution:
Machine-readable exports can stay public by URL structure while still requiring a shared secret token.
Typical setup flow
Configure credentials on the app record
The app edit form stores service-specific values such as tokens, URLs, keys, and secrets directly on the integration instance.
Verify the connection
Apps such as e-conomic and WooCommerce include connection-test actions so teams can validate credentials before enabling automated sync.
Protect inbound requests
Webhook routes validate secrets, and feed routes can require a bearer token before returning data to external consumers.
Audit requests with logs
When credentials fail or remote APIs reject a request, the app log screens make it easier to inspect payloads, status codes, and timing.
Current implementation note
The current repository does include OAuth-based flows for specific apps elsewhere, but I did not find a generic OAuth2 product feature behind this landing page. This page therefore focuses on the authentication mechanisms clearly used by the integration modules and feed endpoints.
Need secure integrations without hiding the implementation details?
Configure credentials per app, verify inbound webhooks, sign outbound payloads, and use API logs to see exactly how each integration is authenticating.