Talk to the people building Apostl

• The public documentation, SDK, API, or product URL you want Apostl to inspect.
• The result a new developer or agent should reach, such as a testnet transaction, an authenticated API response, or an installed server integration.
• The environment and product version that should be treated as canonical.
• Any launch date, customer commitment, or release window that changes the urgency.

Do not email passwords, API keys, wallet seed phrases, private keys, session cookies, or production customer data. Apostl will ask for a safe, scoped credential path only when a private journey has been explicitly agreed.

For a public API problem, include the request URL, HTTP method, response status, stable error code, and a redacted example. The machine-readable contract is published at apostl.dev/openapi.json, and integration guidance lives in the Apostl developer portal.

For Apostl Pulse, include the site origin, server framework, SDK version, and whether URL verification and the first real event succeeded. Never include the Pulse ingest API key or setup token.

Use the same founders address for access, correction, deletion, or other questions about information submitted through this site. The privacy notice describes the current public-site data flow. For a security report, provide enough reproduction detail to identify the affected surface without including secrets or accessing data that is not yours.

Apostl currently publishes email and scheduled video calls as its official contact channels. A postal business address and telephone number are not shown because they have not been approved as official public company details. The team works remotely with developer-infrastructure companies across markets.