Use the Metadata API
The metadata domain is a flexible place to store app-owned facts about resources. It is useful for prototypes, SaaS control planes, feature flags, app settings, and product-specific records that do not need a custom database yet.
Write metadata
curl -X POST "$P6M_URL/v1/metadata" \
-H "Authorization: Bearer $P6M_API_KEY" \
-H 'Content-Type: application/json' \
-d '{
"orgId": "'"$ORG_ID"'",
"workspaceId": "'"$WORKSPACE_ID"'",
"enabledServiceId": "'"$METADATA_SERVICE_ID"'",
"resourceType": "project",
"resourceId": "project_123",
"key": "status",
"value": "active"
}'
Read metadata
curl "$P6M_URL/v1/metadata?orgId=$ORG_ID&enabledServiceId=$METADATA_SERVICE_ID&resourceType=project&resourceId=project_123" \
-H "Authorization: Bearer $P6M_API_KEY"
Design guidance
- Use stable resource IDs from your application.
- Keep values small and structured.
- Use workspaces to separate environments.
- Use policies when writes need tenant-specific validation.
- Do not store secrets in metadata unless customer encryption and secret-specific handling are configured.
What is charged
Metadata charges are based on customer application usage of the metadata domain:
- metadata writes
- metadata reads
- request compute used to process metadata API calls
- metadata storage retained for the customer
- policy-denied metadata write attempts, when an active policy evaluates and rejects the request
Portal views of metadata should not be billed as customer app reads. Billing should come from customer API traffic and retained storage.