Connecting Gemini to Apps Script is technically an HTTP request, but a trustworthy integration needs more than a successful response. It needs secure configuration, bounded input, a documented prompt, defensive parsing, useful failure states, and a clear decision about what humans must review.
Protect credentials and choose the right boundary
Store API keys in Script Properties and never return them to client-side HTML. Restrict who can run the script and what data it can send. Before including document or spreadsheet content, remove unnecessary personal or confidential information and confirm that the chosen service and account configuration are appropriate for the data.
Build prompts as data
Separate stable instructions, task context, user input, and output requirements. Add delimiters and length limits so content cannot accidentally become instructions. Request a defined structure when the result will be processed by code. Save a prompt version so changes can be evaluated and older outputs can be explained.
Handle the HTTP layer deliberately
Set content type, method, payload, and error behavior explicitly. Inspect the response code before parsing. Convert service errors into safe operational messages and log enough metadata to diagnose quotas, authorization, or malformed requests without recording sensitive prompt content.
Validate model output
Treat generated text as untrusted. Confirm required fields, types, lengths, and allowed values. Remove unsupported markup before inserting content into Docs or emails. If parsing fails, preserve the original user input and offer a retry rather than silently using partial data.
Keep humans at consequential decisions
Use drafts, suggestions, classifications, or summaries as reviewable outputs. Do not let generated content automatically send external communication or overwrite important records unless the risk is understood and controls are strong. Measure quality with representative examples and track when people correct the result.
Build an evaluation set
Collect representative inputs, difficult edge cases, and examples that must be refused or escalated. Define what a useful output contains and which errors are unacceptable. Run the set whenever the prompt, model, or parsing code changes. Compare results by accuracy, completeness, format validity, unsupported claims, and correction effort rather than selecting the response that merely sounds most polished.