Skip to content

Getting Started

AvelinLabs is best evaluated as a structured decision service, not as a generic chat interface.

At the platform level, AvelinLabs exposes decision intelligence through APIs. In the current beta documentation, the first supported domain is U.S. labor market intelligence: job data, skill signals, O*NET 30.3-grounded occupation intelligence, and market context.

The public API endpoint is live at https://api.avelinlabs.com, but runtime product endpoints require an active runtime API key. During beta, keys are issued through controlled early-access onboarding.

Public documentation and examples are available for evaluation now. The flow below documents the beta platform and runtime-key model for users who have been granted access; it should not be read as fully open self-service production access for arbitrary public users.

During beta, the platform flow is API-first: register through the Platform API, verify your email, create or receive an enabled runtime API key under the current beta access policy, and use that key on product endpoints.

POST /api/v1/platform/register

Registration creates a developer identity and dispatches a verification email.

{
"email": "[email protected]",
"password": "ChangeMe123!",
"full_name": "Alex Morgan",
"company_name": "Example Company"
}

Illustrative beta response snippet:

{
"status": "pending_verification",
"message": "Verification email sent",
"next_step": "Check your inbox and verify your email address before logging in."
}

GET /api/v1/platform/verify-email?token=...

The verification link activates the developer identity. When eligible, beta access is activated as part of the verification flow.

Illustrative beta response snippet:

{
"status": "verified",
"beta_access": "activated",
"message": "Email verified successfully",
"next_step": "Your Beta access has been activated. You can now log in and create a Runtime API Key."
}

POST /api/v1/platform/login

Login returns a management bearer token for account and API-key management. This token is not used on product endpoints.

{
"email": "[email protected]",
"password": "ChangeMe123!"
}

Illustrative beta response snippet:

{
"access_token": "<management-bearer-token>",
"token_type": "bearer"
}

POST /api/v1/platform/api-keys/create

Use the management bearer token from login to create a runtime API key when that operation is enabled for your beta account. During controlled beta, runtime API keys may also be issued manually to early-access users.

Authorization: Bearer <management-bearer-token>
{
"name": "local-development"
}

Illustrative beta response snippet:

{
"name": "local-development",
"masked_preview": "avln_sk_...abcd",
"raw_api_key": "<runtime-api-key>",
"status": "active"
}

The raw runtime API key is returned once. Store it securely before leaving the response.

Use the runtime API key on product endpoints such as job analysis, job classification, occupation intelligence, and market intelligence:

Authorization: Bearer <runtime-api-key>

Use the public API base URL for Platform API and runtime product endpoints:

https://api.avelinlabs.com

Runtime product endpoints use a customer runtime API key sent as a bearer token:

Authorization: Bearer <runtime-api-key>

Runtime product endpoints require an active runtime API key. During controlled beta, runtime API keys are issued manually to early-access users or enabled through the documented beta platform flow. Store API keys securely and never commit them to source control.

The public readiness endpoint, GET /health/ready, does not require authentication.

  1. Choose a documented API area.
  2. Prepare enough input signal for the task.
  3. Call the API using the current beta contract.
  4. Review structured outputs, confidence fields, and explanations.
  5. Decide how your application should use, display, or route the result.
  1. Confirm that your account has controlled beta access.
  2. Register with POST /api/v1/platform/register if instructed by the beta onboarding flow.
  3. Verify your email with GET /api/v1/platform/verify-email?token=....
  4. Log in with POST /api/v1/platform/login.
  5. Create or receive an active runtime API key according to the current beta access policy.
  6. Set the base URL to https://api.avelinlabs.com.
  7. Send Authorization: Bearer <runtime-api-key> with product API requests.
  8. Call a public endpoint such as POST /api/v1/job/classify.
  9. Interpret confidence, uncertainty, decision, and explanation fields in your workflow.
  10. Review the official examples repository for executable examples and sample payloads.
Terminal window
curl -X POST "https://api.avelinlabs.com/api/v1/job/classify" \
-H "Authorization: Bearer <runtime-api-key>" \
-H "Content-Type: application/json" \
-d '{
"title": "Help Desk Technician",
"description": "Resolve user support issues, troubleshoot hardware and software problems, document incidents, and escalate complex tickets.",
"debug": false
}'

Illustrative beta response snippet:

{
"occupation": {
"onet_code": "15-1232.00",
"title": "Computer User Support Specialists"
},
"confidence": 0.88,
"trust_score": 0.82,
"confidence_level": "HIGH",
"uncertainty": {
"total": 0.18
},
"decision": {
"decision": "AUTO_ACCEPT",
"reason": "Confidence and uncertainty meet the configured decision threshold."
}
}

For labor market intelligence workflows, stronger inputs usually produce more useful outputs. Job titles, job descriptions, location context, and skill-bearing text can help support occupation classification, skill signal extraction, ranking, and confidence-aware scoring.

Sparse or ambiguous input may still return a result, but it should be handled conservatively in downstream workflows.

AvelinLabs uses structured occupation intelligence and labor-market signals to support classification, matching, scoring, and explanation. The current public documentation focuses on U.S. labor market signals, job-market and skill intelligence, and O*NET 30.3-grounded occupation intelligence.

Outputs should be interpreted as decision-support signals for a workflow, not as exhaustive market truth.

A typical integration consumes:

  • top ranked results or classification output
  • occupation metadata where available
  • matched or extracted skill signals
  • confidence, trust, and uncertainty fields
  • quality and explanation fields
  • decision labels that help route results into automation or review

Use high-confidence, low-uncertainty results for automation only when your product policy allows it. Route ambiguous, low-signal, or medium-confidence outputs to human review or downstream approval.

Because AvelinLabs is in beta / early access, integrations should tolerate additive response changes and should avoid assuming that early examples are final contracts.

Treat submitted job text, descriptions, skill-bearing content, and API outputs as customer data. Avoid submitting secrets, credentials, unnecessary personal data, or content that your workflow does not need for classification, matching, scoring, or explanation.

Store runtime API keys in secure application configuration or secret-management systems. Do not place API keys in browser code, public repositories, screenshots, tickets, or example payloads.

When troubleshooting during beta, use any available request_id from an API error response. Beta access is controlled through early-access onboarding and usage may be governed by onboarding, quota, or contract terms.