Using the Pineglass API
Request URLs
The URL used for Pineglass requests depends on the target environment. The endpoint is always /graphql, while the host changes between test and live workspaces.
Test Environment Request URL PINEGLASS_SANDBOX_URL Live Environment Request URL PINEGLASS_API_URL
Authentication
Pineglass authenticates each API request with HTTP Basic authentication. Use your API key as the username and leave the password empty. Review obtaining API keys for the dashboard workflow.
Pass the key through an Authorization header using its base64-encoded value. Invalid or missing credentials receive a 401 Unauthorized response.
Obtaining an API key
Developers
Open the Pineglass dashboard, choose Developers, then create a new key. Copy it immediately: secret keys are shown once and may be revoked whenever necessary.
# Basic authentication Authorization: Basic cGdfbGl2ZV84Y2E0ZTo= curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Basic cGdfbGl2ZV84Y2E0ZTo=" \ --data '{"query":"query Ping { ping }"}'
Headers
Every request requires Authorization and Content-Type. Pineglass accepts and returns JSON, so set Content-Type to application/json.
Status codes
The following HTTP codes may be returned:
| Status code | Scenario |
|---|---|
200 OK | The operation completed, even when GraphQL-level errors are included. |
400 Bad Request | The query failed validation or required input is missing. |
401 Unauthorized | Credentials are missing, revoked, or incorrect. |
5xx | A Pineglass service encountered an unexpected problem. |
Response bodies
Responses use JSON and may contain the following top-level properties:
| Response | Description |
|---|---|
data | The result of the requested operation, matching its selection shape. |
errors | A list of problems encountered while parsing or resolving the request. |
extensions | Additional diagnostic information such as request identifiers. |
For troubleshooting guidance, review request IDs and error handling.
Request body
The API accepts POST requests with JSON payloads. Each request must include a query string and may include variables and operationName.
query
The query field contains the GraphQL query, mutation, or subscription being called.
{ "query": "{ ping }" }
Multiple operations can be represented in one line when required:
{
"query": "query Ping { ping } mutation Refresh { refresh }"
}
variables
The variables field passes dynamic values into queries and mutations. This example describes a new issue-card request:
mutation IssueCard($input: IssueCardInput!) { issueCard(input: $input) { id status } }
The JSON payload supplies the associated values:
{
"query": "mutation IssueCard($input: IssueCardInput!) { issueCard(input: $input) { id status } }",
"variables": {
"input": {
"accountId": "acct_7cb18",
"ownerLabel": "operations",
"options": {
"activateOnCreate": true,
"expirationDate": "2027-01-17T23:50:00Z"
}
}
}
}
Learn more about passing strongly typed GraphQL variables in the API reference.
operationName
When a GraphQL document contains several operations, use operationName to tell the server exactly which one to execute.
query HelloWorld { ping } mutation IssueCard($input: IssueCardInput!) { issueCard(input: $input) { id } }
Payload:
{
"query": "…",
"operationName": "HelloWorld"
}
Read more about using operationName in the reference.