Schema Support

The simulator supports both the Azure Event Grid schema and the CloudEvents v1.0 schema.

Using the Simulator

Once configured and running, requests are POSTed to a topic endpoint. The endpoint format is:

https://localhost:<configured-port>/api/events?api-version=2018-01-01

Event Grid Schema

cURL Example

curl -k -H "Content-Type: application/json" -H "aeg-sas-key: TheLocal+DevelopmentKey=" -X POST "https://localhost:60101/api/events?api-version=2018-01-01" -d @Data.json

Data.json

[
  {
    "id": "8727823",
    "subject": "/example/subject",
    "data": {
      "MyProperty": "This is my awesome data!"
    },
    "eventType": "Example.DataType",
    "eventTime": "2019-01-01T00:00:00.000Z",
    "dataVersion": "1"
  }
]

Event Grid Schema Validation

Field	Description
Id	Must be a string. Not null or whitespace.
Subject	Must be a string. Not null or whitespace.
EventType	Must be a string. Not null or whitespace.
EventTime	Must be a valid date/time.
MetadataVersion	Must be null or 1.
Topic	Leave null or empty. Event Grid will populate this field.
DataVersion	Optional. e.g. 1.
Data	Optional. Any custom object.

CloudEvents Schema

The simulator supports CloudEvents in three modes: structured, batch, and binary.

Structured Mode

In structured mode, the entire CloudEvent is sent as the request body.

cURL Example

curl -k -H "Content-Type: application/cloudevents+json" -H "aeg-sas-key: TheLocal+DevelopmentKey=" -X POST "https://localhost:60101/api/events?api-version=2018-01-01" -d @CloudEvent.json

CloudEvent.json

{
  "specversion": "1.0",
  "type": "com.example.someevent",
  "source": "/mycontext/subcontext",
  "id": "A234-1234-1234",
  "time": "2025-01-15T10:30:00Z",
  "subject": "/example/subject",
  "datacontenttype": "application/json",
  "data": {
    "MyProperty": "This is my awesome data!"
  }
}

Batch Mode

In batch mode, multiple CloudEvents are sent as a JSON array:

cURL Example

curl -k -H "Content-Type: application/cloudevents-batch+json" -H "aeg-sas-key: TheLocal+DevelopmentKey=" -X POST "https://localhost:60101/api/events?api-version=2018-01-01" -d @CloudEventsBatch.json

CloudEventsBatch.json

[
  {
    "specversion": "1.0",
    "type": "com.example.event1",
    "source": "/mycontext",
    "id": "event-1",
    "data": { "message": "First event" }
  },
  {
    "specversion": "1.0",
    "type": "com.example.event2",
    "source": "/mycontext",
    "id": "event-2",
    "data": { "message": "Second event" }
  }
]

Binary Mode

In binary mode, CloudEvents attributes are passed as HTTP headers:

curl -k \
  -H "Content-Type: application/json" \
  -H "aeg-sas-key: TheLocal+DevelopmentKey=" \
  -H "ce-specversion: 1.0" \
  -H "ce-type: com.example.someevent" \
  -H "ce-source: /mycontext/subcontext" \
  -H "ce-id: A234-1234-1234" \
  -H "ce-time: 2025-01-15T10:30:00Z" \
  -H "ce-subject: /example/subject" \
  -X POST "https://localhost:60101/api/events?api-version=2018-01-01" \
  -d '{"MyProperty": "This is my awesome data!"}'

CloudEvents Schema Validation

Field	Description
specversion	Must be 1.0.
type	Must be a string. Not null or whitespace.
source	Must be a string. Not null or whitespace.
id	Must be a string. Not null or whitespace.
time	Optional. Must be a valid RFC 3339 timestamp if provided.
subject	Optional.
datacontenttype	Optional.
dataschema	Optional. Must be a valid URI if provided.
data	Optional. Cannot be used together with data_base64.
data_base64	Optional. Base64-encoded binary data. Cannot be used with data.

Using Postman

An example request that you can import into Postman can be found in the repository:

https://github.com/pm7y/AzureEventGridSimulator/blob/master/src/Azure%20Event%20Grid%20Simulator.postman_collection.json

Using EventGridClient

var client = new EventGridClient(new TopicCredentials("TheLocal+DevelopmentKey="));
await client.PublishEventsWithHttpMessagesAsync(
    topicHostname: "localhost:60101",
    events: new List<EventGridEvent> { <your event> });

Schema Conversion

The simulator can convert between schemas. Use these topic settings:

• inputSchema: The expected schema for incoming events (EventGridSchema or CloudEventV1_0)
• outputSchema: The schema to use when delivering to subscribers

If not specified, the input schema is auto-detected and events are delivered in the same schema they were received in.

Individual subscribers can also override the delivery schema using the deliverySchema setting.

Related Topics

• Topics - Input and output schema configuration
• Configuration - Complete configuration reference