CRUD Operation Code Sample Prompt Template

This prompt is designed for API documentation engineers and DevRel teams who need to generate a complete Create-Read-Update-Delete (CRUD) lifecycle code sample for a single resource type. It produces a runnable sequence that demonstrates proper resource creation, retrieval, modification, and deletion, with error handling at each step and explicit cleanup logic. Use this when your documentation requires a realistic, multi-step workflow example that a developer can copy, run in order, and adapt. The ideal user has access to the target API's specification, understands the authentication model, and needs to show developers how stateful resources behave across their entire lifecycle rather than in isolated endpoint calls.

Do not use this prompt for single-endpoint snippets, authentication-only flows, or examples that do not require stateful resource lifecycle management. It is also a poor fit when the target API lacks a full CRUD surface, when resources are immutable, or when the documentation goal is to explain a single concept like pagination or error codes in isolation. Before invoking this prompt, ensure you can provide the base URL, authentication method, resource schema, and expected success and error response shapes. Without these inputs, the generated sample will be generic and likely incorrect. For high-risk production APIs, always route the output through a validation harness that executes the generated code against a sandbox environment to confirm the sequence compiles, runs, and cleans up resources without leaving orphaned state.

After reviewing this playbook, you should be able to copy the prompt template, substitute your API-specific placeholders, and integrate the resulting code sample into your documentation site or developer portal. The next sections cover the exact prompt template, implementation harness requirements, evaluation criteria, and common failure modes you will encounter when generating stateful CRUD examples at scale.

This prompt template generates a full lifecycle code sample for a single API resource. It is designed for documentation engineers who need to produce runnable Create, Read, Update, and Delete examples that handle errors, clean up resources, and demonstrate production-adjacent patterns like idempotency keys and partial updates. The template uses square-bracket placeholders for all variable parts—resource name, language, HTTP client library, base URL, authentication method, endpoint paths, update fields, and resource schema—so you can adapt it across different APIs without rewriting the structural instructions. Before using this prompt, ensure you have the complete API contract for the target resource, including the exact JSON schema for creation and the expected response shapes for each operation.

codeCopy
Generate a complete, executable CRUD code sample for the [RESOURCE_NAME] resource using the [LANGUAGE] programming language and the [HTTP_CLIENT_LIBRARY] library. The code sample must demonstrate the full lifecycle: Create, Read, Update, and Delete. Include explicit resource cleanup at the end, even if earlier steps fail. Handle errors at each step with try/catch blocks, and log meaningful error messages without exposing credentials. The Create operation must include an idempotency key. The Read operation must validate the returned resource matches the created one. The Update operation must demonstrate a partial update with only the fields specified in [UPDATE_FIELDS]. The Delete operation must verify the resource is gone by attempting a subsequent read and confirming a 404 status. Use the following API details: Base URL: [BASE_URL], Authentication: [AUTH_METHOD], Create Endpoint: [CREATE_ENDPOINT], Read Endpoint: [READ_ENDPOINT], Update Endpoint: [UPDATE_ENDPOINT], Delete Endpoint: [DELETE_ENDPOINT]. The resource schema for creation is: [RESOURCE_SCHEMA]. Wrap the entire sequence in a main function that returns a success or failure exit code. Add comments explaining the purpose of each step, not the syntax.

To adapt this template, replace each square-bracket placeholder with concrete values. For [RESOURCE_NAME], use a human-readable name like "user" or "billing account"—this appears in comments and log messages, not in the API calls. For [LANGUAGE], specify the target language (e.g., Python, TypeScript, Go, Java) and ensure the [HTTP_CLIENT_LIBRARY] is idiomatic for that ecosystem (e.g., requests for Python, fetch with node-fetch for TypeScript, net/http for Go). The [AUTH_METHOD] should describe the exact header or token format (e.g., "Bearer token in Authorization header" or "API key in X-API-Key header"). The [RESOURCE_SCHEMA] must be a valid JSON object with example values that the Create operation will send. The [UPDATE_FIELDS] should list only the subset of fields to change during the partial update, demonstrating that unspecified fields remain unchanged. After generating the code sample, run it against a sandbox environment to verify it compiles, executes without unhandled exceptions, and cleans up the created resource even when intermediate steps fail. For high-risk production APIs, add a human review step to confirm the cleanup logic runs in a finally block or equivalent, and that no credentials appear in logs or error messages.

The CRUD Operation Code Sample Prompt Template is designed to be a component in a larger documentation generation pipeline, not a standalone tool. To use it in production, you must call the LLM with the resolved prompt template and pipe the raw output through a validation harness before any code sample reaches a developer-facing documentation page. The harness acts as a quality gate, ensuring that every published example compiles, handles errors correctly, and contains no security anti-patterns. Without this step, you risk publishing code that fails silently, leaks mock credentials, or teaches unsafe patterns to your API consumers.

The validation harness should execute a strict, ordered pipeline. First, extract the primary code block from the model response using a language-aware fence parser. Write the extracted code to a temporary file named for the target language (e.g., crud_example.py). Second, attempt to compile or lint the code using the standard toolchain for that language—rustc --check, gofmt, eslint, or equivalent—and capture any syntax or static analysis errors. Third, run a credential scan using a tool like detect-secrets or gitleaks to flag any hardcoded API keys, tokens, or passwords. Fourth, if a sandboxed API mock is available, execute the code against it, providing both a success response and a simulated 409 Conflict or 500 Internal Server Error to verify that the error-handling branches are reachable and functional. Finally, log the model identifier, prompt version, timestamp, and the pass/fail result of each validation step to an audit table for traceability.

If any validation step fails, do not publish the code sample. Instead, construct a repair prompt that includes the original prompt, the model's failing output, and the specific error messages from the linter, credential scanner, or test runner. Instruct the model to fix only the identified failures while preserving the original structure and intent. Retry the validation pipeline with the repaired output. Set a maximum retry limit of three attempts to prevent infinite loops. If the code sample still fails after three repairs, flag it for human review and log the full failure chain. The most critical gates are the credential scan and the error-handling completeness check—a code sample that passes compilation but swallows exceptions silently or contains a hardcoded secret is worse than no sample at all.