This part of the documentation covers the Event object.

Event Objects

class, session=None)

The Event object. It structures and handles the data returned by via the Events section of the GitHub API.

Two events can be compared like so:

e1 == e2
e1 != e2

And that is equivalent to: == !=
actor = None

User object representing the actor.

created_at = None

datetime object representing when the event was created.


Return an instance of cls formed from json.

id = None

Unique id of the event


Indicates whether the Event is public or not.


This will be deprecated in 0.6

Returns:bool – True if event is pubic, False otherwise
static list_types()

List available payload types

org = None

List all possible types of Events

payload = None

Dictionary with the payload. Payload structure is defined by type.

public = None

Indicates whether the Event is public or not.


Number of requests before GitHub imposes a ratelimit.


Re-retrieve the information for this object and returns the refreshed instance.

Parameters:conditional (bool) – If True, then we will search for a stored header (‘Last-Modified’, or ‘ETag’) on the object and send that as described in the Conditional Requests section of the docs

The reasoning for the return value is the following example:

repos = [r.refresh() for r in g.iter_repos('kennethreitz')]

Without the return value, that would be an array of None‘s and you would otherwise have to do:

repos = [r for i in g.iter_repos('kennethreitz')]
[r.refresh() for r in repos]

Which is really an anti-pattern.

Changed in version 0.5.

repo = None

Return tuple(owner, repository_name)


Return the json representing this object.

type = None

Event type

When accessing the payload of the event, you should notice that you receive a dictionary where the keys depend on the event type. Note:

  • where they reference an array in the documentation but index it like a dictionary, you are given a regular dictionary

  • where they reference a key as returning an object, you receive the equivalent object from the dictionary, e.g., for a Fork Event:

    >>> event
    <Event [Fork]>
    >>> event.payload
    {u'forkee': <Repository [eweap/redactor-js]>}
    >>> event.payload['forkee']
    <Repository [eweap/redactor-js]>

Using the dictionary returned as the payload makes far more sense than creating an object for the payload in this instance. For one, creating a class for each payload type would be insanity. I did it once, but it isn’t worth the effort. Having individual handlers as we have now which modify the payload to use our objects when available is more sensible.