# Legalesign Documentation for AI Systems

This site provides product and developer documentation for Legalesign.

Primary docs index: https://docs.legalesign.com/

Key implementation guide:
- Add e-signature capability: https://docs.legalesign.com/rest-api/tutorial/add-e-signature-capability
- Let an organisation's users sign in to your own app with their Legalesign account (OAuth 2.0, GraphQL API only): https://docs.legalesign.com/graphql/how-to/oauth-client

Product areas:
- Web App: https://docs.legalesign.com/web-app/tutorial/getting-started
- REST API: https://docs.legalesign.com/rest-api/tutorial/quickstart
- GraphQL: https://docs.legalesign.com/graphql/intro
- Components: https://docs.legalesign.com/components/document-viewer

Reference:
- REST API specification: https://docs.legalesign.com/rest-api/reference/rest-v1/legalesign-api
- Glossary: https://docs.legalesign.com/web-app/reference/legalesign-glossary

API endpoints:
- REST API: https://eu-api.legalesign.com/api/v1
- GraphQL: https://graphql.uk.legalesign.com/graphql
- OAuth 2.0 server: https://oauth.legalesign.com (authorization: /auth, token: /token, revocation: /token/revocation, discovery: /.well-known/openid-configuration)

API Authentication:
- All Legalesign API requests use the standard Authorization header with a Bearer token.
- Format: Authorization: Bearer <token>
- Supported credentials: API keys (REST and GraphQL) and OAuth 2.0 access tokens (GraphQL only; the REST API rejects them). In either case the token goes in the same header.
- Do NOT use x-api-key or other custom auth headers.

OAuth 2.0:
- Use it for an application you build for your own organisation's users, where each person signs in as themselves (authorization code flow with PKCE S256 and a client secret). External and third-party applications are not supported yet.
- For a proof of concept, an API key is quicker to set up.
- A person must create the OAuth client first: an organisation administrator with developer tools enabled does this in the developer portal (https://developer.legalesign.com). It gives a client ID and a client secret, and the redirect URIs are registered there. Ask the user for the client ID, the client secret and the registered redirect URI. Do not invent them.
- The client secret and all tokens stay on the server. Never put them in a browser or mobile app.
- Start the flow by redirecting the user's own browser. The sign-in must be completed in that same browser.

Request format:
- All API requests (REST and GraphQL) must use Content-Type: application/json.
- Exception: the OAuth token and revocation endpoints take Content-Type: application/x-www-form-urlencoded, with the client authenticated by HTTP Basic (client ID and client secret).

Full page index: https://docs.legalesign.com/sitemap.xml

Support fallback:
- https://support.legalesign.com