One agent, one credential
LetsPing gives each agent its own credential pair. You call POST /api/agents/register from a backend you control, using the project API key. The response includes agent_id and agent_secret. Inside the agent process you use these to sign ingest calls.
curl -X POST "https://letsping.co/api/agents/register" \
-H "Authorization: Bearer PROJECT_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "agent_handle": "support-bot-v3" }'Downstream, every signed call carries the agent identity and can be tied back to this registration event.
Handles you can resolve across projects
You rarely want to expose internal ids outside your own project boundary. That is what agent_handle is for. When you set a handle during registration, other services and agents can call GET /api/agents/resolve?handle=... to get a signed claim with your project and agent identifiers.
curl "https://letsping.co/api/agents/resolve?handle=support-bot-v3"
That claim is enough to route requests, record attestation, or feed into a trust score, without leaking the raw ids you use internally.
How this fits with trust score and escrow
Once each agent has its own credential, LetsPing can attribute behavior to the right actor. That makes trust scores, attestation, and escrow envelopes meaningful. A good record belongs to the agent that earned it, not to a shared human key that might be used by many bots.
To go deeper, see Agent Identity and Credentials and the Agent APIs reference.