Bing Ads Python SDK

Bing Ads Python SDK is Microsoft’s officially maintained client library for the Bing Ads (Microsoft Advertising) REST API version 13. It wraps six underlying services — Campaign Management, Bulk, Reporting, Customer Management, Customer Billing, and Ad Insight — behind a single package so Python applications can create and manage search advertising campaigns, pull performance reports, and administer customer accounts without hand-writing HTTP/OAuth plumbing.

Alongside the per-call service clients, the SDK ships a higher-level Bulk API layer (BulkServiceManager, BulkFileReader/BulkFileWriter, and dozens of bulk-entity classes) for high-volume campaign edits via upload/download files rather than one-request-per-entity calls, which is the practical way most agencies and ad-tech platforms manage large account structures at scale.

What You Get

• Typed clients for all six Bing Ads v13 REST services (Campaign Management, Bulk, Reporting, Customer Management, Customer Billing, Ad Insight), generated from Microsoft’s official API spec
• A BulkServiceManager plus BulkFileReader/BulkFileWriter for uploading and downloading large campaign structures as bulk files instead of one API call per entity
• Built-in OAuth2 flow support via AuthorizationData and related classes for authenticating against production and sandbox environments
• Pydantic v2-backed generated models (openapi_client) giving structured request/response objects instead of raw JSON dictionaries
• Dozens of runnable example scripts under examples/v13/ covering campaigns, ad extensions, remarketing lists, offline conversions, and more

Common Use Cases

• Programmatically creating and updating search/shopping campaigns, ad groups, ads, and keywords from an internal marketing tool
• Bulk-editing thousands of keywords, bids, or budgets across accounts via the Bulk API instead of individual entity calls
• Pulling scheduled performance reports (clicks, conversions, spend) into a data warehouse or BI pipeline
• Building agency/ad-tech platforms that manage multiple advertiser accounts and customers programmatically
• Automating offline conversion imports and audience/remarketing list management

Under The Hood

Architecture The SDK layers a hand-authored bingads package on top of an auto-generated openapi_client (produced via an OpenAPI generator per .openapi-generator-ignore and generate_all.bat/generate_proxies.ps1), which supplies six service API classes — CampaignManagementServiceApi, BulkServiceApi, ReportingServiceApi, CustomerManagementServiceApi, CustomerBillingServiceApi, AdInsightServiceApi — and an extensive tree of pydantic model files under openapi_client/models. The hand-written layer wraps these low-level clients with a friendlier surface: service_client.py’s _CampaignObjectFactoryV13 reflects over the pydantic models to construct campaign objects while caching class resolution and construction specs to avoid repeated per-call overhead, authorization.py implements the OAuth2 token/AuthorizationData flow, and v13/bulk/ supplies BulkServiceManager alongside BulkFileReader/BulkFileWriter and a large set of bulk-entity classes for the separate high-throughput Bulk API. Because the low-level layer is code-generated from Microsoft’s API spec, most functional changes flow from spec regeneration rather than hand-editing; the hand-written layer is the stable integration surface applications actually depend on.

Tech Stack Python, supporting 3.8 through 3.12, with a lean dependency set: requests for HTTP, pydantic/pydantic-core (v2) for the generated models, python-dateutil, urllib3, and typing-extensions. There’s no web or ORM framework since this is an outbound API client, not a server. Packaging is classic setuptools (setup.py), published to PyPI as bingads/msads. CI runs on Azure Pipelines (azure-pipelines.yml), but the pipeline only builds and publishes an sdist artifact — it does not execute a test suite. tox.ini and test-requirements.txt reference pytest, pytest-cov, flake8, and mypy for local development, targeting the SDK’s own generated REST layer against Microsoft’s Bing Ads API v13.

Code Quality There is no genuine automated unit-test suite in the repository — the only *_test.py files live under examples/v13/ and are runnable usage demonstrations against a live account (they require real developer tokens/credentials and print output), not assertion-based tests. tox.ini’s configured environments (py33, py34) predate the package’s actual supported Python range (3.8-3.12), and the Azure Pipelines CI job never invokes pytest, flake8, or mypy despite all three being listed as dev dependencies. Error handling uses a small custom exception hierarchy (SdkException and OAuthTokenRequestException, duplicated with slightly different signatures between bingads/exceptions.py and bingads/authorization.py). Type safety is reasonable on the generated openapi_client half thanks to pydantic v2 models, but the hand-written bingads layer is largely untyped classic Python relying on docstrings rather than type hints. Overall: no enforced automated testing, partial type coverage.

What Makes It Unique The SDK’s value isn’t architectural novelty — it’s comprehensive, spec-accurate coverage of Microsoft’s evolving Bing Ads/Microsoft Advertising API surface (six services, extensive bulk-entity coverage, and OAuth flows) that would be impractical for most teams to hand-roll and keep in sync with Microsoft’s own release notes. Developer experience is mixed: getting started requires noticeable boilerplate (constructing AuthorizationData, an OAuth grant, and a per-service client), and public model field naming inherits inconsistencies from the underlying XML/REST schema rather than idiomatic Python conventions. The Bulk API layer (BulkServiceManager plus file reader/writer) is meaningfully higher-level and more pleasant than calling the raw entity APIs one at a time, which is the SDK’s strongest ergonomic contribution. Overall this follows standard client-SDK patterns rather than introducing a novel approach.