Skip to main content
Help improve the examples and documentation through the public OneFunnel API samples repository. You can open an issue, submit a fix, contribute another language or author a complete application tutorial. Repository contributions use Apache-2.0; review its contribution instructions before opening a pull request.

​
Choose the right route

  • A sample bug: open a sample bug report with the sample path, runtime, steps and expected versus actual behavior.
  • Unclear or incorrect documentation: open a documentation report with the affected portal URL and suggested correction.
  • A new example, language or full tutorial: open a sample or tutorial proposal. Describe the developer task and expected result before investing in a large implementation.
  • A developer-experience or API feature suggestion: open a feature proposal explaining the use case and current workaround. A proposal does not change the published API contract or promise a delivery date.
  • Account access, credentials, billing or a specific API request: contact Support privately with sanitized diagnostic information.
  • A suspected security vulnerability: use the repository’s private vulnerability reporting form. Follow its security policy; do not disclose vulnerability details in a public issue.
Public issues and pull requests are visible to everyone. Do not include access tokens, signing secrets, OTP codes, customer details or private account data.

​
Contribute a fix

For a small, reproducible sample or README fix, fork the public repository, create a branch, make the change and run that sample’s offline tests. Open a pull request explaining the problem, the fix and your test results. Link its issue if one exists. See the sample README for commands; repository-wide tooling is optional when running an individual application. For a portal-only wording or navigation correction, use a documentation issue with the page URL and proposed replacement. The portal source is private, so external contributors do not need access to it; maintainers apply reviewed portal corrections there.

​
Author a complete tutorial

  1. Propose the task, language, prerequisites and final result in a public issue. Check existing samples and tutorials to avoid duplicate implementations.
  2. Build a runnable application at samples/<api-area>/<task>/<language>/, following the repository’s structure conventions.
  3. Include source, offline tests, placeholder configuration and a README with setup, expected outcomes, recovery and operational boundaries. Add the sample to the catalog and CI as described in the contribution instructions.
  4. Write the full walkthrough in tutorial.md beside the sample README. Explain each step from environment setup to the saved outcome; link to canonical API operations instead of copying their schemas. Follow the tutorial authoring checklist.
  5. Open a pull request linking the proposal, application, tutorial draft and offline test results. State separately whether a live Sandbox exercise was performed; never make live requests a default test step.
Maintainers review correctness, clarity, safety and consistency with the published API. Review may require changes. Acceptance of a sample or draft does not automatically publish it in the portal: maintainers prepare the portal change, arrange the required review and post publication status on the public contribution, including the public page URL when it is available. Attribution can be requested in the contribution PR; do not include private contact details in a public draft.

​
Help without writing code

You can improve wording, report an inaccessible example, reproduce an issue, suggest a missing task or share a sanitized workaround in the relevant issue. Keep discussion respectful and focused on reproducible behavior and developer needs. Use Support for private account conversations.