English Product Guides

API Authentication: v1 Bearer Tokens & Authorization

EarthCoop's current /api/v1 first-party/native-client contract includes an explicit bearer-token authentication flow. This is stronger evidence than the older state where only Sanctum-protected routes were visible without a documented issuance path.

Current v1 login

The current native session controller accepts the member's email and password at the v1 login endpoint and validates the required EarthCoop agreement state. On successful authentication it issues the current bearer token and returns bootstrapped member data used by the client.

Conceptually:

POST /api/v1/auth/login
Accept: application/json
Content-Type: application/json

The exact request/response fields should be taken from the current controller/tests rather than copied into a permanent external SDK contract without review.

Presenting the token

Protected v1 requests use the standard bearer authorization header:

Authorization: Bearer YOUR_TOKEN
Accept: application/json

The token authenticates the member. It does not grant permissions beyond that member's current EarthCoop rights.

Logout and revocation

The current v1 logout path revokes/deletes the token that authenticated the request. Clients should therefore treat logout as a server-side credential revocation event, not merely as local deletion of cached session state.

Authentication is not authorization

A valid token answers who the requester is. The requested domain operation can still require:

• ownership of the target record;
• the applicable member/group role;
• election or governance eligibility;
• monetary-state and account rules;
• current policy/configuration gates;
• other domain-specific authorization.

For NajmHoda, a valid token also does not turn client-supplied page or actor context into authority. The server re-resolves trusted context before action-capable flows can execute.

Web and Google authentication are separate product flows

The EarthCoop web application also has its own session-based authentication paths, including the current Google OAuth flow. Their existence does not mean a native bearer token should be obtained by scraping a browser session or reusing a third-party provider credential directly against arbitrary v1 endpoints.

The supported v1 bearer token is issued by EarthCoop's own current native-session contract.

Third-party/public API boundary

The existence of a v1 bearer-token flow proves a current first-party/native-client authentication contract. It does not by itself establish a general developer-platform policy for third-party apps, arbitrary personal access tokens, long-lived token management, OAuth scopes, refresh tokens, or an external credential portal.

Those capabilities should be documented only if a specific supported contract is introduced.

Error handling

Login can fail for invalid credentials, invalid/missing agreement state, validation errors, or other current account restrictions. Protected requests can fail authentication or later authorization. Clients should preserve that distinction rather than treating every rejection as an invalid password.