.png)
Amazon Bedrock Integration Guide
Amazon Bedrock integrates with enterprise systems through AWS-authenticated HTTPS APIs for model inference, agents, knowledge bases, guardrails, and batch processing.
Amazon Bedrock integration options at a glance
Amazon Bedrock exposes modeled AWS service APIs over HTTPS for model invocation, conversational inference, agents, knowledge bases, guardrails, and related runtime operations. Requests generally require AWS Signature Version 4 signing and IAM authorization. Bedrock also supports asynchronous batch inference, selected document and image content, and knowledge-base ingestion from supported data sources such as Amazon S3. It does not provide a general-purpose webhook model, so asynchronous workflows typically poll operation status or use AWS event services and intermediaries. Martini can orchestrate these calls, expose APIs for applications, transform model-specific JSON, schedule polling, validate responses, and apply custom signing logic when required.
| Integration point | Supported by Amazon Bedrock? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST and HTTPS service APIs | Limited | Bedrock exposes modeled AWS service APIs for model invocation, Converse, agents, knowledge bases, guardrails, inference profiles, and control-plane operations. These are operation-oriented AWS APIs rather than consistently conventional REST resources. | Martini can consume HTTPS APIs and orchestrate operation-specific requests. AWS Region, service name, payload hashing, and SigV4 signing must be configured or implemented for the selected operation. |
| Model invocation APIs | Yes | InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream support synchronous or streaming interactions with supported foundation models. | Martini workflows can map prompts or messages into model-specific JSON, invoke the operation, normalize responses, and route streaming or long-running processing appropriately. |
| Agents and knowledge-base APIs | Yes | Runtime APIs can invoke Bedrock Agents and retrieve or generate answers from Knowledge Bases, including retrieval and retrieval-and-generation workflows. | Martini can expose a consistent enterprise API over one or more agents or knowledge bases, validate authorization context, map citations and results, and apply downstream business rules. |
| Bulk and asynchronous batch APIs | Yes | Batch inference processes large volumes of input asynchronously, such as document classification, summarization, embedding generation, and content enrichment. | Martini can start and monitor batch jobs, persist job identifiers and locations, poll status on a schedule, process results, and retry transient failures without duplicating downstream actions. |
| File and document content | Limited | Selected runtime operations accept document or image content, while Knowledge Bases ingest content from supported data sources such as Amazon S3. This is not a universal attachment API. | Martini can validate content references and metadata, map supported content blocks, coordinate S3-based workflows, and route unsupported formats to an exception path. |
| AWS events and notifications | Limited | Bedrock can participate in selected AWS event and monitoring integrations, but it does not provide a general-purpose webhook subscription model for all operations. | Martini can expose an authenticated API for AWS intermediaries or poll operation status from scheduled workflows. Event availability must be verified per Bedrock operation. |
| AWS IAM and SigV4 authentication | Yes | Bedrock uses IAM authorization and generally requires AWS Signature Version 4 request signing. Temporary credentials, IAM roles, policies, and resource permissions control access. | Martini can keep credentials and signing configuration in secure environment settings or secrets. Custom JVM-compatible logic or an authenticated intermediary may be needed when direct signing is unavailable. |
| AWS SDKs | Yes | AWS SDKs provide service models and assist with authentication and request signing in supported programming languages. | Martini can use reusable JVM-compatible helper logic or services when an SDK is the most reliable way to handle SigV4 and provider-specific payloads. |
How Amazon Bedrock exposes data and business events
Amazon Bedrock HTTPS APIs
Amazon Bedrock exposes modeled AWS service APIs over HTTPS for runtime and control-plane operations. The API surface includes model invocation, Converse, agents, knowledge bases, guardrails, inference profiles, and batch-related operations, with operation-specific payloads and AWS authentication requirements.
Martini implementation pattern
Martini implementation pattern: a workflow receives an application request or scheduled trigger, builds the operation-specific JSON payload, applies AWS signing through configured capability or reusable custom JVM-compatible logic, calls Bedrock, validates the response, and returns or persists a normalized result.
Implementation sequence
Model invocation and Converse
Bedrock supports InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream for interactions with supported foundation models. Direct invocation schemas vary by provider and model family, while Converse offers a more standardized conversational structure where supported.
Martini implementation pattern
Martini implementation pattern: the workflow selects a configured model or inference profile, maps canonical prompts or messages into the required schema, invokes the selected runtime operation, validates structured output, and routes streaming or timeout-sensitive work separately.
Implementation sequence
Agents and Knowledge Bases
Bedrock Agents can perform multi-step tasks using instructions, action groups, knowledge bases, and foundation models. Knowledge Bases support retrieval and retrieval-and-generation patterns for enterprise content.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API for consuming applications, validates tenant and authorization context, invokes the selected agent or knowledge-base operation, maps citations and action results, and applies business rules before returning or writing the response.
Implementation sequence
Batch inference and asynchronous processing
Amazon Bedrock supports batch inference jobs for large-scale asynchronous processing, including summarization, classification, embedding generation, and content enrichment. Input and output locations commonly involve Amazon S3.
Martini implementation pattern
Martini implementation pattern: a scheduler or business event starts a workflow that creates or monitors a batch job, stores job identifiers and locations, polls status or consumes a supported AWS event through an intermediary, and processes results once completion is confirmed.
Implementation sequence
Common Amazon Bedrock integration patterns
Pattern 1: Summarize enterprise documents
When to use this pattern
Use this pattern when business applications need a consistent document summarization service rather than separate model-invocation implementations. The workflow can validate content, choose a model, control sensitive logging, and return a normalized summary.
Integration direction
Example Mapping
| Amazon Bedrock Field | Canonical Field | Target Field |
|---|---|---|
| documentReference | source.documentUri | document or content block |
| summaryInstructions | prompt.instructions | messages or prompt |
| generatedText | summary.text | application.summary |
| modelResponseId | processing.correlationId | application.aiRequestId |
Martini implementation pattern
A Martini API receives a document reference or request, validates and retrieves supported content, maps the request to Converse or InvokeModel, and validates the response before returning it. Business rules can reject oversized or unsupported content, while bounded retries address transient throttling without repeating downstream writes.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- JSON processing
- business rules
- error handling
Pattern 2: Provide knowledge-base question answering
When to use this pattern
Use this pattern when several applications need one governed interface over Bedrock Knowledge Bases. It centralizes authorization context, retrieval behavior, citation mapping, and response validation.
Integration direction
Example Mapping
| Amazon Bedrock Field | Canonical Field | Target Field |
|---|---|---|
| question | query.text | retrieval query |
| tenantId | security.tenantId | authorized knowledge-base context |
| retrievedReferences | answer.sources | response.citations |
| generatedAnswer | answer.text | application.answer |
Martini implementation pattern
Martini receives and validates the question, tenant, and user context, invokes retrieval or retrieval-and-generation, maps citations and answer content into a stable contract, and rejects incomplete or unsafe output. Correlation identifiers and controlled logging support troubleshooting without exposing full confidential prompts or documents.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- validation
- security configuration
- error handling
Pattern 3: Run batch content enrichment
When to use this pattern
Use this pattern for large-scale or offline processing that should not depend on a synchronous HTTP timeout. It is suitable for classification, summarization, embedding generation, and periodic content enrichment.
Integration direction
Example Mapping
| Amazon Bedrock Field | Canonical Field | Target Field |
|---|---|---|
| inputLocation | batch.inputUri | Bedrock input location |
| jobId | processing.externalJobId | batch job identifier |
| jobStatus | processing.status | workflow state |
| outputLocation | batch.outputUri | S3 result location |
Martini implementation pattern
A scheduled Martini workflow validates the S3-based input and output configuration, starts or identifies the batch job, persists its identifier, and polls until completion or failure. Completed output is mapped into downstream records, while idempotency keys, checkpoints, bounded retries, and restart handling prevent duplicate processing.
Martini capabilities used
- scheduler triggers
- workflows
- API consumption
- data mapping
- business rules
- error handling
- monitoring
Pattern 4: Govern agent-assisted business actions
When to use this pattern
Use this pattern when an agent can assist a process but its generated parameters must not directly control business-system writes. Martini provides the API boundary, authorization checks, allowlists, and downstream orchestration.
Integration direction
Example Mapping
| Amazon Bedrock Field | Canonical Field | Target Field |
|---|---|---|
| businessRequest | request.intent | agent input |
| accountOrCaseId | context.businessObjectId | agent context |
| proposedAction | decision.action | validated downstream action |
| actionResult | transaction.result | source application status |
Martini implementation pattern
Martini receives the originating application request, selects an approved Agent, invokes it with constrained context, validates generated parameters and action results, and calls the downstream application only when allowlists and authorization rules pass. Failed validation, throttling, or agent errors follow an explicit retry or manual-review path.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- validation
- error handling
Applications commonly integrated with Amazon Bedrock
Amazon Bedrock is commonly placed within AWS and enterprise application architectures to add model inference, retrieval, summarization, classification, and agent-assisted actions. Martini can coordinate these systems without assuming a dedicated native connector, using their APIs, AWS event services, secure credentials, and reusable workflows.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Amazon S3 | S3 can store knowledge-base source documents, batch inference input, generated output, and model-processing artifacts. | Amazon S3 → Martini → Amazon Bedrock | Martini retrieves or validates object references, invokes the appropriate Bedrock operation, tracks job identifiers and output locations, and transforms results for downstream processing. |
| AWS Lambda | Lambda can provide custom request signing, document preparation, post-processing, or controlled business actions around Bedrock. | Martini → AWS Lambda → Amazon Bedrock | A Martini workflow can call or be called by Lambda through an authenticated API boundary, while keeping orchestration, validation, retries, and response normalization in the workflow. |
| Amazon EventBridge | EventBridge can route AWS service or application events that trigger Bedrock processing or help monitor selected asynchronous operations. | Amazon EventBridge → Martini → Amazon Bedrock | Martini exposes an API for approved event delivery, validates event context, starts or checks a Bedrock operation, and records correlation and job identifiers. |
| Amazon OpenSearch Service | OpenSearch can support enterprise content search and retrieval architectures associated with generative AI applications. | Amazon OpenSearch Service → Martini → Amazon Bedrock | Martini can coordinate content retrieval or indexing flows, map search results into a knowledge or prompt context, invoke Bedrock, and validate generated output before persistence. |
| Salesforce | Salesforce data can be summarized, classified, enriched, or used to generate agent-assisted responses and business context. | Salesforce → Martini → Amazon Bedrock | Martini receives a Salesforce request or scheduled workload, invokes Bedrock with a controlled payload, validates the response, and updates approved Salesforce fields or objects through its APIs. |
| ServiceNow | ServiceNow incidents, cases, and knowledge content can be summarized, classified, or used in service-desk assistance workflows. | ServiceNow → Martini → Amazon Bedrock | A Martini API or workflow receives ServiceNow data, invokes a selected model or agent, validates generated fields and actions, and returns or writes a normalized response through ServiceNow APIs. |
| Jira | Jira issues can be summarized, classified, enriched, or used to draft release and project communications. | Jira → Martini → Amazon Bedrock | Martini retrieves approved Jira issue data, maps it to a model-specific prompt or Converse request, validates the result, and updates Jira or a documentation process with bounded retries. |
| Slack | Slack can provide controlled conversational access to enterprise knowledge or AI-assisted workflow actions. | Slack → Martini → Amazon Bedrock | A Slack event or application request reaches a Martini API, which authenticates the context, invokes Bedrock or a knowledge base, validates the response, and sends a normalized reply through the Slack API. |
How to build a Amazon Bedrock integration in Martini
Objective
Establish the AWS access model for the required Bedrock Region, operation, model, agent, or knowledge base without embedding long-lived credentials in workflow logic.
Instructions in Martini
- Configure IAM permissions for only the required Bedrock operations and resources
- Store temporary credentials, role settings, Region, and model identifiers in secure environment configuration
- Determine how SigV4 signing will be performed for the selected operation
- Validate model access and Region availability before production use
Objective
Select the execution style that matches the Bedrock operation and business latency requirement.
Instructions in Martini
- Use an API request for interactive model, agent, or knowledge-base calls
- Use a scheduler for batch status polling or periodic enrichment
- Use an approved AWS event intermediary only when the specific event is available
- Use a Martini API when an external application or AWS service must submit a request or callback
Objective
Prepare prompts, messages, documents, or batch locations while respecting operation-specific content support.
Instructions in Martini
- Retrieve or validate source documents and object references
- Check model-specific content, size, and format requirements
- Load the latest batch, knowledge-base, or resource status when polling
- Preserve correlation and idempotency identifiers across calls
Objective
Build the end-to-end Martini workflow that invokes Bedrock and coordinates downstream processing.
Instructions in Martini
- Resolve the selected Bedrock operation and configuration
- Construct the provider-specific request payload
- Invoke Bedrock through an authenticated HTTPS request or reusable signing logic
- Route synchronous, streaming, and asynchronous operations through appropriate workflow paths
Objective
Convert provider-specific request and response schemas into stable internal and application-facing models.
Instructions in Martini
- Map canonical prompts or messages to Converse or InvokeModel payloads
- Parse and validate model-generated JSON before downstream use
- Map citations, job status, action results, and response metadata
- Apply required-field, type, length, and allowed-value rules
Objective
Ensure generated content or agent actions are safe and authorized before they affect business systems.
Instructions in Martini
- Verify tenant, user, resource, and downstream authorization context
- Use allowlists for agent actions and permitted target operations
- Mask sensitive prompts, documents, and responses in operational logs
- Route invalid, unsafe, or incomplete output to review or exception handling
Common Amazon Bedrock data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Foundation models | Select the model provider, model identifier, and supported inference capabilities for a request. | Salesforce, ServiceNow, Jira, Amazon S3, internal applications | Martini stores model identifiers and Region settings as environment configuration, applies model-specific mappings, and routes unsupported model features to validation errors. |
| Model invocation requests and responses | Carry prompts, conversational messages, structured output, embeddings, images, or generated text returned by runtime operations. | Business applications, databases, APIs, content platforms | Martini maps request payloads, invokes Converse or InvokeModel where appropriate, validates generated output, masks sensitive content in logs, and normalizes provider-specific responses. |
| Inference profiles | Route inference requests across supported models or Regions and manage invocation behavior. | Internal AI gateways, enterprise applications, reporting systems | Martini resolves the configured profile, Region, and model context at runtime and records correlation data for operational troubleshooting. |
| Agents | Orchestrate foundation models, instructions, action groups, and knowledge bases for multi-step tasks. | ServiceNow, Salesforce, Jira, internal business APIs | Martini invokes selected agents, validates agent-generated parameters and action results, applies allowlists and authorization rules, and controls downstream writes. |
| Knowledge bases | Retrieve relevant enterprise content or perform retrieval-augmented generation for application questions. | Customer portals, service applications, Slack, internal APIs | Martini validates tenant and user context, calls retrieval or retrieval-and-generation operations, maps citations and answers, and exposes a stable application-facing contract. |
| Batch inference jobs | Track asynchronous, large-scale model processing and its input and output locations. | Amazon S3, databases, reporting platforms, content systems | Martini starts or monitors jobs, persists job identifiers and checkpoints, polls status, processes output locations, and applies bounded retries and restart handling. |
Authentication and security considerations
AWS authentication
Amazon Bedrock generally requires AWS Signature Version 4 signing and IAM authorization. Permissions can be scoped by operation, Region, model, agent, knowledge base, and other resource attributes.
Credential protection
Use temporary credentials issued through IAM roles, AWS STS, or another workload identity mechanism where possible. Martini should keep credentials, Regions, model identifiers, and signing configuration in secure environment settings or secrets.
Data protection
- Treat prompts, retrieved documents, model responses, and agent inputs as potentially confidential.
- Avoid logging complete payloads by default and apply masking, retention, and access controls.
- Validate model-generated content and agent parameters before sending them to business systems.
Operational considerations for Amazon Bedrock integrations
Quotas and throttling
Bedrock quotas and model throughput limits vary by operation and provisioning model. Use bounded retries with exponential backoff and jitter, and control concurrency to avoid amplifying throttling.
Regions and schemas
Model, agent, knowledge-base, inference-profile, and quota availability can vary by AWS Region. Keep Regions and model identifiers configurable, and maintain model-specific request and response mappings.
Asynchronous processing
Batch jobs and long-running operations should use checkpoints and scheduled polling or verified AWS events rather than ordinary short request-response assumptions. Continue paginated API calls until the returned pagination token is absent.
Idempotency and validation
- Persist correlation, job, and idempotency identifiers where supported.
- Do not assume model invocation is idempotent; protect downstream writes separately.
- Validate structured output before updating Salesforce, ServiceNow, Jira, databases, or other systems.
- Test model-specific payloads, streaming behavior, timeouts, and schema changes independently.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate the complete process
Scripts often combine authentication, model-specific payloads, retries, validation, and downstream updates in one code path. Martini separates these concerns into reusable workflows and APIs that can be monitored and maintained as requirements change.
Standardize application access
Martini can expose a controlled API over Bedrock Agents, Knowledge Bases, or model operations so multiple applications use consistent authorization, mappings, response contracts, and business rules.
Handle operational complexity
- Orchestrate synchronous, streaming, scheduled, and batch processing patterns.
- Apply transformations and validation before model output reaches business systems.
- Centralize error handling, retry behavior, correlation, and secure configuration.
- Extend workflows with custom JVM-compatible logic when SigV4 signing or provider-specific processing requires it.
Frequently asked questions
Amazon Bedrock can be integrated through its modeled HTTPS service APIs for model invocation, Converse, Agents, Knowledge Bases, guardrails, inference profiles, and batch inference. Integrations generally use AWS IAM authorization and SigV4 request signing, with scheduled polling or AWS event intermediaries for asynchronous operations.
Yes. Martini can integrate with Amazon Bedrock by consuming its HTTPS service APIs, orchestrating workflows, exposing APIs for applications or callbacks, transforming model-specific JSON, scheduling batch polling, and using secure AWS authentication or custom JVM-compatible signing logic where required.
No. A dedicated Amazon Bedrock connector is not required. Martini can use Bedrock's native HTTPS APIs, IAM and SigV4 authentication, supported batch and knowledge-base operations, and AWS event or intermediary patterns where applicable.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amazon Bedrock with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from AWS, infrastructure providers, or other third-party systems based on subscription, model usage, storage, and deployment choices.
Use Converse or direct InvokeModel operations for supported synchronous model interactions, Agent runtime APIs for agent-assisted processes, Knowledge Bases APIs for retrieval workflows, and batch inference for large asynchronous workloads. The correct choice depends on model support, payload schema, latency, and processing volume.
Bedrock does not provide a general-purpose webhook subscription model for all operations. Selected AWS event integrations may be available, but coverage must be confirmed per operation. Martini can instead poll asynchronous status or expose an API for an AWS service or intermediary to call.
Martini can use API-triggered, scheduled, or event-assisted workflows to retrieve inputs, invoke Bedrock, and write normalized results to business systems. Model-specific request and response mappings should be maintained explicitly, with validation for generated JSON, citations, action results, and batch output.
Workflows can distinguish throttling, authorization, validation, timeout, model-availability, batch, and ingestion failures. Bounded exponential backoff with jitter is appropriate for transient throttling, while correlation identifiers, persisted checkpoints, client tokens where supported, and downstream idempotency controls help prevent duplicate business actions.
Related Martini documentation
Build reliable Amazon Bedrock integrations with Martini
Use Martini to orchestrate Amazon Bedrock APIs, secure AWS authentication, model-specific mappings, knowledge-base workflows, batch processing, and governed application responses.