.png)
Weights & Biases Integration Guide
Connect Weights & Biases projects, runs, artifacts, and automation events with enterprise systems through GraphQL, REST, webhooks, and orchestrated Martini workflows.
Weights & Biases integration options at a glance
Weights & Biases provides GraphQL as a primary interface for querying and mutating supported Projects, Runs, Artifacts, Sweeps, Reports, and Tables. Documented REST endpoints are also available for selected operations, while the W&B SDK provides another supported programmatic interface. W&B Automations can emit webhook-style notifications for selected events, and Artifacts provide versioned datasets, models, and files. Martini can consume GraphQL and REST APIs, receive selected callbacks through a REST API, orchestrate artifact operations, paginate through results, apply mappings and governance rules, and synchronize data with databases, storage services, deployment platforms, and reporting systems.
| Integration point | Supported by Weights & Biases? | Common use cases | How Martini supports it |
|---|---|---|---|
| GraphQL APIs | Yes | Query and mutate supported Projects, Runs, Artifacts, Sweeps, Reports, and Tables with explicit field selection and nested responses. | Martini can consume the W&B GraphQL endpoint, send queries or mutations, handle cursor-based pagination, map nested responses, and apply GraphQL-specific error handling. |
| REST APIs | Limited | Use documented HTTP endpoints for selected W&B operations where the required object or action is available through REST. | Martini can consume documented W&B REST endpoints and keep the base URL, credentials, and endpoint choices environment-specific. Each operation should be verified against the deployed W&B product. |
| Webhooks | Limited | W&B Automations can send webhook-style notifications for selected Run, Artifact, or other supported platform events and actions. | Martini can expose a REST API or use a webhook workflow trigger, validate incoming requests, enrich event data through W&B APIs, and process longer work asynchronously. |
| File and Artifact APIs | Limited | Manage versioned datasets, models, evaluation outputs, logged files, and Artifact metadata as part of ML workflows. | Martini can orchestrate documented Artifact and file operations, preserve names, versions, aliases, and digests, and coordinate with cloud storage APIs without assuming a generic attachment API. |
| W&B SDK | Yes | Use the supported Python SDK for W&B-specific programmatic behavior and operations not conveniently exposed through a documented HTTP endpoint. | Martini can integrate directly through HTTP APIs in most cases. SDK-specific behavior may require a compatible external service or custom JVM-compatible logic. |
| Authentication | Yes | Authenticate with user API keys or service-account API keys subject to organization, team, and project permissions. | Martini can store credentials in secrets or environment configuration, inject them into API requests, and keep deployment-specific W&B URLs configurable. |
| Batch and asynchronous operations | Not confirmed | Runs and Artifacts are associated with asynchronous ML jobs, but a general-purpose bulk API for all W&B objects was not confirmed. | Martini can implement bounded batches using pagination, scheduling, checkpoints, and retry handling rather than assuming a vendor bulk endpoint. |
| Database access | No | Direct database access to the hosted W&B platform was not confirmed. | Martini should use W&B APIs, SDK-compatible services, supported exports, or automation callbacks instead of a direct platform database connection. |
How Weights & Biases exposes data and business events
Weights & Biases GraphQL APIs
GraphQL is a primary W&B interface for querying and mutating supported Projects, Runs, Artifacts, Sweeps, Reports, and Tables. It uses explicit field selection and may return nested data with cursor-based pagination. Available operations and fields can vary by object and deployment.
Martini implementation pattern
Martini implementation pattern: a workflow sends an authenticated GraphQL query or mutation, follows cursors, validates the response and permission errors, maps the selected fields to a canonical model, and writes or routes the result to an enterprise target.
Implementation sequence
Weights & Biases REST APIs
W&B documents HTTP APIs for selected operations, although GraphQL and the SDK are more prominent for many platform data tasks. Endpoint availability should be verified for the W&B product and deployment in use.
Martini implementation pattern
Martini implementation pattern: a workflow calls the documented REST operation, handles the configured W&B base URL and authentication, normalizes the response, and applies retry and idempotency rules before updating a target system.
Implementation sequence
Weights & Biases Webhooks
W&B Automations supports webhook-style notifications for selected platform events and actions. Coverage is event-specific and should not be generalized to every Run, Artifact, Project, or field change.
Martini implementation pattern
Martini implementation pattern: Martini exposes a protected REST API, receives the selected callback, validates its event type and authentication or signing controls, acknowledges quickly, and starts asynchronous enrichment through W&B APIs.
Implementation sequence
Weights & Biases Artifacts and files
Artifacts represent versioned datasets, models, evaluation outputs, and other files. Metadata and file contents may require separate operations, and a generic attachment endpoint should not be assumed.
Martini implementation pattern
Martini implementation pattern: a workflow retrieves Artifact metadata, evaluates aliases, versions, digests, and lineage, then coordinates supported W&B operations with a storage or deployment API while avoiding unnecessary loading of large files into memory.
Implementation sequence
Common Weights & Biases integration patterns
Pattern 1: Synchronize training Runs to an analytics platform
When to use this pattern
Use this pattern when engineering or governance teams need an incremental view of training and evaluation activity outside W&B. The workflow retrieves updated Runs from selected Projects, preserves project context and metrics, and avoids full-project reloads.
Integration direction
Example Mapping
| Weights & Biases Field | Canonical Field | Target Field |
|---|---|---|
| Run.id | externalRunId | run_id |
| Run.name | runName | run_name |
| Run.summaryMetrics | summaryMetrics | metrics_json |
| Run.state | runStatus | status |
Martini implementation pattern
A scheduled Martini workflow queries W&B GraphQL with bounded pages and a durable cursor or timestamp checkpoint. It maps Run configuration and summary metrics, validates project ownership, upserts by stable Run identifier, and retries transient failures without duplicating downstream rows.
Martini capabilities used
- scheduled workflows
- GraphQL API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Promote approved Artifacts to deployment
When to use this pattern
Use this pattern when a model or dataset Artifact must pass governance checks before a downstream deployment or release process begins. The trigger may be a selected W&B automation callback or a scheduled review workflow.
Integration direction
Example Mapping
| Weights & Biases Field | Canonical Field | Target Field |
|---|---|---|
| Artifact.name | artifactName | model_name |
| Artifact.version | artifactVersion | version |
| Artifact.aliases | releaseLabels | deployment_labels |
| Run.summaryMetrics | evaluationMetrics | quality_metrics |
Martini implementation pattern
Martini receives a selected event or retrieves candidate Artifacts on a schedule, then fetches related Run metadata. It checks required aliases, digests, evaluation thresholds, ownership, and approval fields before calling the deployment API. Failed validations stop promotion, while transient API errors are retried and deployment results are recorded.
Martini capabilities used
- webhook receiving
- workflow orchestration
- API consumption
- data mapping
- validation rules
- retry handling
Pattern 3: Route W&B automation events to Slack
When to use this pattern
Use this pattern when teams need targeted notifications for selected Run or Artifact events without coupling W&B directly to every downstream notification rule. Event coverage must be explicitly configured for the W&B deployment.
Integration direction
Example Mapping
| Weights & Biases Field | Canonical Field | Target Field |
|---|---|---|
| event.type | eventType | notification_title |
| event.project | projectName | project |
| event.runId | runId | run_reference |
| event.artifactVersion | artifactVersion | artifact |
Martini implementation pattern
Martini exposes a REST endpoint for W&B automation callbacks, validates the event and any available authentication controls, enriches the payload through GraphQL, applies team and severity routing rules, and sends a Slack message. Event identifiers and delivery status are retained to handle duplicate callbacks safely.
Martini capabilities used
- REST API exposure
- webhook workflow triggers
- GraphQL API consumption
- business rules
- idempotency
- monitoring
Pattern 4: Build an ML governance report
When to use this pattern
Use this pattern when compliance or platform teams need a normalized view of Projects, Runs, Artifacts, Sweeps, and Reports. It supports scheduled extraction, validation, and publication to a warehouse or internal reporting API.
Integration direction
Example Mapping
| Weights & Biases Field | Canonical Field | Target Field |
|---|---|---|
| Project.name | projectName | project_name |
| Run.config | experimentConfiguration | configuration_json |
| Artifact.digest | artifactDigest | artifact_digest |
| Sweep.name | sweepName | sweep_name |
Martini implementation pattern
A scheduled Martini workflow retrieves the required W&B objects in bounded pages, applies rules for ownership, required Artifacts, evaluation thresholds, and retention, then transforms the result into a governance schema. It writes idempotently, logs rejected objects, and checkpoints each object class independently.
Martini capabilities used
- scheduled workflows
- GraphQL API consumption
- pagination
- data transformation
- validation
- logging and error handling
Applications commonly integrated with Weights & Biases
Weights & Biases can be integrated with adjacent engineering, storage, orchestration, notification, observability, and machine-learning platforms. The exact direction and implementation depend on the W&B deployment, available API operations, and the objects being exchanged.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| GitHub | Associate commits, branches, and pull requests with Runs and coordinate model-development automation. | GitHub → Martini → Weights & Biases | Martini can receive repository or workflow events, transform source metadata, and call W&B APIs to associate context with Projects or Runs. Selected W&B automation events can also be routed to GitHub Actions or repository workflows through a controlled API. |
| Amazon S3 | Exchange datasets, model files, checkpoints, and Artifact content with AWS object storage. | Amazon S3 → Martini → Weights & Biases | Martini can coordinate W&B Artifact metadata with S3 object operations, preserve versions and digests, and apply validation before moving or promoting files. Artifact operations should use documented W&B capabilities rather than assuming a generic attachment endpoint. |
| Google Cloud Storage | Support dataset, checkpoint, and model-file workflows for teams running ML workloads in Google Cloud. | Google Cloud Storage → Martini → Weights & Biases | A Martini workflow can retrieve Artifact metadata, call supported storage APIs, validate object locations and checksums, and publish a normalized result to W&B or an internal governance system. |
| Microsoft Azure Blob Storage | Exchange training data, model outputs, and Artifact files with Azure-based ML environments. | Microsoft Azure Blob Storage → Martini → Weights & Biases | Martini can orchestrate Azure Blob Storage operations alongside W&B API calls, apply naming and retention rules, and record Artifact lineage or deployment outcomes in an enterprise system. |
| Slack | Notify engineering and research teams about selected Run, Artifact, or automation events. | Weights & Biases → Martini → Slack | Martini can receive a selected W&B automation callback, enrich it with Run or Artifact metadata, apply routing rules, and send a concise notification to Slack while preventing duplicate event delivery. |
| Datadog | Correlate ML workflow information with infrastructure and operational observability data. | Weights & Biases → Martini → Datadog | Martini can normalize selected W&B event or workflow data and forward it to Datadog using an approved API, while retaining correlation identifiers and handling transient delivery failures. |
| Apache Airflow | Coordinate scheduled training, evaluation, synchronization, and Artifact workflows. | Apache Airflow → Martini → Weights & Biases | Airflow can invoke a Martini API or workflow for W&B synchronization, while Martini handles authentication, pagination, mapping, governance rules, and status callbacks using W&B GraphQL or REST operations. |
| MLflow | Exchange or migrate experiment and model metadata between machine-learning lifecycle platforms. | MLflow → Martini → Weights & Biases | Martini can map MLflow experiments and model metadata to W&B Projects, Runs, and Artifacts, or perform the reverse transformation. Stable identifiers, field-level compatibility rules, and retry-safe upserts are required. |
How to build a Weights & Biases integration in Martini
Objective
Configure the W&B deployment URL and authentication without embedding credentials in workflow definitions.
Instructions in Martini
- Use a W&B API key or service-account API key appropriate for the workflow.
- Store credentials in Martini secrets or environment configuration.
- Configure organization, team, project, and deployment-specific access assumptions.
Objective
Select an event-driven or scheduled entry point based on the W&B operation and its available automation coverage.
Instructions in Martini
- Use a webhook workflow trigger for selected W&B Automations events.
- Use a scheduler for incremental Run, Artifact, or governance synchronization.
- Expose a Martini REST API when W&B needs to call an integration endpoint.
Objective
Call the appropriate W&B interface and retrieve only the objects and fields required by the integration.
Instructions in Martini
- Prefer GraphQL for supported object queries and mutations.
- Use documented REST operations where they provide the required capability.
- Implement cursor pagination, bounded batches, and durable checkpoints.
Objective
Coordinate enrichment, validation, downstream calls, and status handling in a maintainable Martini workflow.
Instructions in Martini
- Retrieve related Projects, Runs, or Artifact metadata when an event payload is incomplete.
- Separate metadata processing from large file movement.
- Route valid, rejected, and transient-failure outcomes explicitly.
Objective
Convert W&B-specific structures into a stable enterprise model while preserving lineage and identifiers.
Instructions in Martini
- Map Run metrics, configuration, state, and timestamps to canonical fields.
- Preserve Artifact versions, aliases, digests, and lineage references.
- Handle optional fields and nested GraphQL responses defensively.
Objective
Enforce governance and operational policies before writing data or promoting an Artifact.
Instructions in Martini
- Validate project ownership and permitted teams.
- Check required tags, aliases, evaluation metrics, and approval fields.
- Use stable W&B identifiers for idempotent upserts and duplicate prevention.
Common Weights & Biases data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Projects | Organize experiments, Runs, Artifacts, dashboards, and related ML work. | Data warehouses, governance platforms, reporting services, GitHub | Martini queries Projects through GraphQL or documented REST operations, maps ownership and configuration fields, and uses project identifiers as stable integration keys. |
| Runs | Represent training, evaluation, or job executions with configuration, metrics, summaries, system information, and logged files. | Databases, analytics platforms, Datadog, governance systems | Martini retrieves Runs incrementally with pagination and checkpoints, maps state and metrics to a canonical model, and performs idempotent upserts. |
| Artifacts | Version datasets, models, evaluation outputs, and other files used by Runs. | Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, deployment platforms | Martini separates Artifact metadata from file movement, preserves aliases, versions, digests, and lineage, and invokes supported W&B or storage APIs. |
| Sweeps | Define and track hyperparameter-search processes and their associated Runs. | Analytics platforms, governance systems, Apache Airflow | Martini retrieves Sweep definitions and related Run information, normalizes search metadata, and applies project or ownership validation rules. |
| Reports | Provide shareable analytical documents and visualizations built from W&B data. | Compliance repositories, internal reporting APIs, knowledge platforms | Martini can retrieve supported Report data, transform relevant metadata, and publish governance or reporting extracts without assuming every presentation feature is API-accessible. |
| Tables | Store structured datasets for tracking, visualization, comparison, and evaluation workflows. | Data warehouses, evaluation services, cloud storage | Martini can query supported Table data, transform structured fields, and route extracts to approved enterprise targets while handling schema variation defensively. |
Authentication and security considerations
API keys and service accounts
Weights & Biases programmatic integrations commonly use user API keys or service-account API keys. Service accounts are appropriate for unattended synchronization, CI/CD, scheduled workflows, and deployment processes.
Credential protection
Store W&B credentials in Martini secrets or environment configuration. Do not embed API keys in workflow mappings, source code, or request templates.
Permissions and deployment controls
Authentication does not guarantee access to every organization, team, or Project. Apply least privilege and test permissions for each W&B object the workflow reads or writes. Keep Cloud and Enterprise base URLs configurable because endpoints and identity controls can differ.
Operational considerations for Weights & Biases integrations
Pagination and request volume
Use cursor-based pagination, bounded batches, incremental checkpoints, and scheduled synchronization rather than repeatedly retrieving all Runs or Artifacts. Confirm applicable limits for the W&B deployment and avoid unnecessary concurrency.
Idempotency and retries
Use stable W&B identifiers, Artifact versions, or digests as external keys. Implement upserts, exponential backoff for transient HTTP or GraphQL failures, and processed-event tracking where callback identifiers are available.
Artifacts and files
Handle Artifact metadata separately from large file content. Preserve names, versions, aliases, digests, and lineage, and confirm whether a required operation belongs in W&B, a documented SDK-compatible service, or a storage provider.
Schema and webhook changes
Select only required GraphQL fields, handle optional values defensively, and test event payloads against the deployed W&B configuration. Validate callback authentication, event types, replay protection, and duplicate delivery.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a maintainable workflow for authentication, pagination, enrichment, transformation, business rules, downstream API calls, and status handling rather than scattering logic across separate scripts.
Reusable integration assets
Teams can expose controlled APIs, reuse mappings and validation logic, and keep W&B-specific transformations separate from canonical enterprise models. This supports scheduled, event-driven, and API-led integration patterns.
Operational reliability
Martini can apply checkpoints, idempotent writes, retries, validation, logging, and environment-specific configuration. These controls are important for asynchronous ML workflows and for handling evolving GraphQL schemas, permissions, and Artifact lifecycles.
Frequently asked questions
Weights & Biases can be integrated through its GraphQL API, documented REST endpoints, W&B SDK-compatible services, selected Automations webhooks, and Artifact or file operations. Common solutions synchronize Projects and Runs, promote Artifacts, publish governance data, and route selected ML events to downstream systems.
Yes. Martini can consume the W&B GraphQL API, use documented REST endpoints, receive selected W&B webhook or automation events, and orchestrate Artifact and storage operations. A dedicated native Martini connector was not documented in the supplied research.
No. A dedicated Weights & Biases connector is not required. Martini can use W&B's confirmed GraphQL API, documented REST operations, API-key authentication, selected webhook callbacks, and supported Artifact or file mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Weights & Biases. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from W&B, cloud infrastructure, storage providers, or other third-party systems.
GraphQL is the primary interface to consider for many W&B platform objects, including Projects, Runs, Artifacts, Sweeps, Reports, and Tables. REST is suitable where W&B documents the required operation. The choice should be verified against the customer deployment and object-level capability.
Yes, Martini can expose a REST API and receive W&B automation callbacks. W&B webhook-style notifications are available for selected events and actions, not necessarily every object or field change, so the accepted event types and payload controls should be documented explicitly.
Use GraphQL cursors or another supported checkpoint, bounded batches, and incremental filters where available. Stable Project, Run, Artifact, and Report identifiers should be used for idempotent upserts, while processed event identifiers and retry-safe writes help prevent duplicates.
Yes. Martini can expose a controlled REST API that abstracts selected W&B queries or mutations for internal consumers. The façade can centralize authentication, validation, field mapping, permissions-aware routing, error handling, and deployment-specific W&B endpoint configuration.
Related Martini documentation
Martini APIs
Operations
Connect Weights & Biases with your enterprise systems
Use Martini to build secure, observable workflows around Weights & Biases APIs, selected automation events, Artifacts, and ML governance processes.