Developer resources for Share My Data

March 20, 2023

What’s new:

1. Release of a new API HTTP response code (204) for both synchronous and asynchronous API calls to indicate when no data is available for the requested range.
2. Supporting an x-transaction header label that supports the ability to link PG&E’s response to specific Asynchronous API calls by returning this value along with a Correlation ID when the requested file is ready.
3. Improved additional data granularity to the UsagePoint/MeterReadingID API by providing electric interval data for multiple meters to single Service Agreement scenarios.
4. Provided additional clarity to Reading Quality Indicator values for ESTIMATED interval data to describe the type of estimation used for that interval. New values indicating estimation logic has been applied are below:

5. Release of vendor API usage metrics in the Share My Data Third Party vendor portal.

November 15, 2018

What's new:

1. Customer Class Indicator has been added. Each SAID that is authorized will be identified as either RES, AGR, COM/IND or Other.
2. Billing and Usage APIs will be updated to accept updated-max and updated-min query parameters (as an alternative to published-min and published-max). The data returned will be all changes that have occurred within the updated-max and updated-min parameters.
3. Replacing the use of a third party's 5-digit Bulk ID with the third party’s Client ID for the online authorization flow.
4. Providing the option for a third party to redirect customers to either PG&E's account login or the Guest Access tab as part of the online authorization flow.
5. Improving PG&E’s Share My Data customer dashboard to make it easier for customers to view all of their existing data sharing authorizations with third parties.

September 27, 2018

What's new:

PG&E added new data elements to the Rule 24 data set as part of PG&E's Expanded Data Set (EDS) project, and corresponding new data elements are introduced in Rule 25 data set. The specific data elements comprising PG&E's expanded Rule 25 data set are set forth below with designation EDS:

Rule 25 Data Elements

Notes
Account Elements
Account Name
Account Address
Account ID
EDS: Outage Block
Service Elements
PG&E UUID
Service ID
Future Changes to Status of Service
SA Status
Service Start Date
Service Address
Current Service Tariff
Historical Billed Service Tariff
Tariff Options (Medical Baseline, CARE, FERA, TBS, CCA_TBS, Solar Choice
Current Service Voltage and Commodity Historical Billed Service Voltage
Service Meter Number
Number of Service Meters
Meter Type
Current Meter Read Cycle
Historical Billed Meter Read Cycle
Current Standby Rate Option if On-site Generation Indicator
Historical Billed Standby Rate Option
EDS: Customer Class Indicator
Historical Billing Elements
Bill start date
Bill end date
Bill total charges($)
Bill total kWh
EDS: Name of Service Provider
Historical Bill Tier Breakdown (if any)
EDS: Line Item Bill Period
EDS: Name (Over Baseline 1%-30%)
EDS: Volume (1234.2)
EDS: Rate ($0.032/kWh)
EDS: Cost ($100.23)
Historical Bill TOU kWh breakdown (except for ABS-TX billed)
EDS: Line Item Bill Period (for TOU breakdown)
EDS: Name (of TOU charge)
EDS: Volume (1234.2)
EDS: Rate ($0.032/kWh)
EDS: Cost ($100.23)
Historical Bill Demand Breakdown
EDS: Line Item Bill Period (for Demand breakdown)
EDS: Name
EDS: Volume (1234.2)
EDS: Rate ($0.032/kWh)
EDS: Cost ($100.23)
Historical Bill Line Items
EDS: Line Item Bill Period
EDS: Charge name (DWR Bond Charge)
EDS: Volume (1234.2)
EDS: Unit (kWh)
EDS: Rate ($0.032/kWh)
EDS: Cost ($100.23)
Historical Usage Intervals
Interval Usage Start
Default Interval Duration (in seconds)
Interval usage Volume (1234.2)
Unit (kWh/Therms)
Utility Demand Response Programs
(DR) Program Name
Earliest Termination Date without Financial Obligation
Earliest Termination Date regardless of Financial Obligation
DR Program Status
DR Program Enrollment Date
DR Program De-Enrollment Date
Data Elements
Commodity
Local Time Parameters (DST details)
Default Data Quality
Energy Direction
Power of Ten Multiplier (for interval usage values)
Power of Ten Multiplier (for Billed Demand)
Power of Ten Multiplier (For Billed total usage)
Interval Length(of Usage Reading)
Currency of bill total cost
Electric Interval TOU Indicators

June 28, 2018

As part of the Click-Through project and the continued improvements to the Share My Data Platform, PG&E launched Click-Through Phase 2 on June 28, 2018.

What's new:

The most critical changes that impact third parties are changes to conform to the OAuth 2.0 protocol (PG&E eliminated the initial series of redirects). Find details below.

IMPORTANT: Third parties are REQUIRED to make changes to their existing OAuth implementation. PG&E's Click-Through Phase 2 changes are NOT backwards compatible, so it is necessary for third parties to implement changes concurrent with PG&E's implementation. Without implementation, the current customer authorization process will stop working on the cut-off date of June 29, 2018. Existing authorizations, however, are unaffected.

1. To conform to the OAuth 2.0 protocol, PG&E has reduced the number of redirect steps for authorization. The initial redirect to PG&E for customers to log in and submit an authorization has been combined with the authorization code request as follows:
• As shown in the example below, third-party Authorization code requests now comprise a redirect of the customer's browser to PG&E's new authorizationServerAuthorizationEndpoint URI, along with appropriate request parameters:
  GET https://sharemydata.pge.com/myAuthorization?client_id=xxxxx&redirect_uri={redirect_uri}&response_type=code&state={optionalState}
• The following endpoint has been retired: https://api.pge.com/datacustodian/oauth/v2/authorize...
  
  
2. New error handling messages for authorization code requests with missing or invalid scope parameters as follows:
• If the required client_id or redirect_uri parameters are missing or invalid, an (http 400) error with explanatory message is shown to the customer
• If the required response_type parameter is missing or invalid, the customer will be redirected back to the third party's redirect_uri with an "invalid_request" error parameter (appended to the redirect_uri)
  
  
3. For customers with an existing online authorization, the ability for a third party to request a new access_token/refresh_token pair as part of a new authorization that replaces the existing one (i.e., online authorization of the same third party and customer combination). This functionality addresses scenarios of third parties losing an access_token/refresh_token pair or otherwise needing to change the scope of the original authorization per customer approval.
• For re-authorization requests, the customer sees the new authorization page instead of the "manage authorization" page when redirected by a third party to PG&E for authorization
• Upon customer authorization, third parties receive a notification to their registered notification URL that the old subscription ID is canceled (notification comprises authorization API URL endpoint for the old subscription ID)
  
  
4. The ability for a customer to exit via a "cancel" button on either the authentication page or authorization page with redirect back to the third party's redirect_uri with an "access_denied" error parameter (appended to the redirect_uri)
5. For third parties who register with the "visibility" setting on and are therefore included in the list of registered third parties customers will see when they go to their PG&E online account and navigate to the Share My Data landing page:
• For customers who log in to their PG&E online account and navigate to the Share My Data landing page and are then redirected to third party's registered "Third Party Portal URI" upon selecting a third party from the list of registered third parties. At that point, customers can proceed with the third party initiated OAuth process. When going through this path, customers will no longer be shown the authorization page upon selecting a third party from the dropdown list of third parties, but instead be redirected to the third party's registered "Third Party Portal URI" where they can begin the third party initiated OAuth process
• Note: Some third parties have inquired about how to streamline the customer experience for this use case (i.e., authorizations initiated on PG&E's site) such that to the customer it appears they are taken directly to an authorization page upon selecting a third party from the dropdown. To facilitate such a customer experience, third parties can elect to set their "Third Party Portal URI" (via the Share My Data manage registration page) to an endpoint that automatically redirects the customer back to PG&E as part of an authorization code request. Upon automatic redirect back to PG&E's authorizationServerAuthorizationEndpoint, the customer will skip the customer login page (as they are already logged in) and will go directly to the authorization page. For some third parties who have registered prior to the Share My Data Click Thru 2.0 release, this can be accomplished by simply defining the Third Party Portal URI to equal the no longer used "Third Party Scope Selection Screen"URI (old SMD Registration field to be retired in a future release).
  In contrast, some third parties may want to instead first engage and screen customers on their side when customers are redirected to their 'Third Party Portal' URI before requesting an authorization code, so the above approach is only a suggestion.
  
  
6. SMD will now be providing enhanced Scope parameter details as part of the responses to the Authorization Code Request, the Access Token Request, and the Authorization API. The enhanced scope parameter allows for communicating the final scope of customer authorization. In particular, the scope parameter includes an "AdditionalScope" value that maps to PG&E's supported customer authorization selections of data groups (e.g. "Usage", "Billing", "Basic", "Account", "Program Enrollment"). The scope parameter values are further captured per the following documentation: Download Supported Function Block Scope String Mapping Click Thru 2.0 (PDF, 219 KB)
   
   An example Token response below illustrates some possible scope parameter values.
• Example Token Response:
  
  <Response xmlns="https://api.pge.com/datacustodian/oauth/v2/token">
  <access_token>774ff105-7ad5-40c8-a6ec-f60675dc0e41</access_token>
  <expires_in>3600</expires_in>
  <refresh_token>998c6654-5b3b-4385-af4f-4e5c46c1bb04</refresh_token>
  <scope>scope=FB=1_3_8_13_14_18_19_31_32_35_37_38_39_40_4_5_10_15_16_46_47;AdditionalScope=Usage_Billing_Basic_Account_ProgramEnrollment;IntervalDuration=900_3600;BlockDuration=Daily;HistoryLength={3P Registered historical length};AccountCollection={count of authorized SAs};BR={ThirdPartyID};dataCustodianId=PGE</scope>
  resourceURI:{ResourceURI} e.g: https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Subscription/{subscriptionID}
  authorizationURI:{AuthorizationURI} e.g: https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/{authorizationID}
  customerResourceURI:{customerResourceURI} e.g:https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Batch/RetailCustomer/{RetailCustomerID}
  <token_type>Bearer</token_type>
  </Response>
  
  
7. Third parties can now register to receive authorized Program Enrollment information via the new "Program Enrollment" data group. Both interval metered as well asnon-interval metered customers will be eligible to authorize sharing of data for SMD Click-Through Phase 2. A high-level summary of the newly available data elements provided by the Program Enrollment data group is as follows:
• Program Enrollment (PG&E Demand Response program name/status and CAISO information):
• (Billing) Account address
• Service Agreement Status
• (Current) Service tariff
• (Current) Service voltage (electric only)
• Service meter number (if any)
• Meter type
• (Current) Meter Read Cycle
• (Current) Standby Rate Option if On-Site Generation Indicator
• (default interval usage) Duration (length in seconds)
• (Enrolled PG&E Demand Response) Program Name (if applicable)
• Earliest Termination Date from PG&E enrolled Demand Response (DR) Program without Financial Obligation
• Earliest Termination Date from PG&E enrolled Demand Response (DR) Program regardless of Financial Obligation
• PG&E Demand Response (DR) Program (enrollment) Status
• PG&E Demand Response (DR) Program Enrollment Date
• PG&E Demand Response (DR) Program De-Enrollment Date
• The Atom XML XSD (XML Schema Definition) mapping for these new data elements are captured as per the following documentation:
  Download Supported Data Elements (PDF, 234 KB)
• Associated relational data hierarchy model is outlined per the following:
  Download PGE ESPI Data Model (PDF, 531 KB)
• UsagePoint (aka SA UUID)
  • ServiceDeliveryPoint\tariffProfile(current service tariff AKA rate schedule including Standby Rate Option if applicable)
  • readCycle (current Meter Read Cycle)
• UsageSummary
  • readCycle (billing service cycle)
  • Commodity (includes billed voltage level for electric)
  • tariffProfile (billed service tariff including Standby Rate option if applicable
• Reading Type
  • Commodity (includes current voltage level for electric and prefix for Standby Rate Option where applicable)
• Customer Account
  • (Acct Billing Address):
  • mainAddress/streetDetail...
  • mainAddress/townDetail...
  • mainAddress/postalCode...
• Customer Agreement
  • status\value (SA Status
• Demand Response Program
  • programName
  • enrollmentStatus
  • programDate/programDate
  • programDate/programDateDescription
• Meter
  • serialNumber (meter id)
  • type (meter type)
  • (current) intervalLength
• Latest ESPI xml schema definitions (XSDs) used for these new data element is outlined per the following:
  Download XSDs (ZIP, 49 KB)
  Note: the XSDs are backwards compatible.
• Third parties will have the ability to change their registration to allow customers to select this data group during the time of authorization via the third party portal under manage registration >Edit > section: Indicate the customer information you require", select the Program Enrollment check box.
• Note, this will only apply to new customer authorizations.
  
  
• New APIs to retrieve DR Enrollment information is available at the Bulk 3^rd party level as well as at the individual customer authorization level (RetailCustomerID level), outlined per the following:
  Download new PGE Supported APIs (PDF, 211 KB)
• Asynchronous API for requesting DR Enrollment information for all authorizations to a third party
  • https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Batch/BulkRetailDRPrgInfo/{BulkID}
• Synchronous API for requesting DR enrollment information at the individual customer authorization level
  • https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Batch/RetailDRPrgInfo/{RetailCustomerID}

Please note: Besides the changes to the customer authorization process, other changes are also backwards compatible and are voluntary enhancements third parties can elect to support.

If you have any questions or need additional support, feel free to email sharemydata@pge.com.

What’s new:

1. Customers can now benefit from the streamlined Click-Through authorization process.
   • We’ve updated the details about how a customer can now share data with your company.
     Learn how customers share data with a company
     
     Note: These changes, particularly improvements to our authorization UI, have been optimized for mobile devices (e.g., phones or tablets).
   • Changes have been made to the manage authorization process accessible to customers through their PG&E online account:
     • A customer can still remove SAIDs from an existing authorization, extend the authorization end date and/or cancel the authorization at any time. However, to add additional SAIDs and/or change authorized data elements the existing authorization needs to be cancelled and a new authorization needs to be created.
2. If desired, third parties can now use this API for revoking individual customer authorizations using their third party Client Access Token (provided during initial SMD third party registration process) via a DELETE operation: https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/{AuthorizationID}
   
   Note 1: For PG&E’s implementation, the AuthorizationID parameter is the same value as the SubscriptionID.
   
   Note 2: The new API provides third parties the ability to revoke (cancel) an authorization. However, only customers themselves can remove SA IDs and/or update the authorization end date via our SMD manage authorization pages.
   
   Reminder: As with all API data requests, third parties must first request a new Token Pair (Client Access + Refresh Token) using their latest Refresh Tokens.
   
   Reminder of Token Expiration Periods:
   • Access Token:1hr
   • Client Access Token: 5 min
   • Corresponding Refresh Tokens: 1Yr
3. Third parties can now create multiple Share My Data (SMD) registrations using the same company name and Tax ID if needed. However, the display name (which customers see when authorizing) still needs to be unique.
   
   Note: All of the changes above are backwards compatible and are voluntary enhancements third parties can elect to support. Download supporting documents for this release:
   
   Supported_APIs.SMD_Click-Thru_1.0 (PDF, 213 KB)
   
   Supported_Data_Elements_retailCustomer.SMD_Click_Thru_1.0 (PDF, 200 KB)
   
   PGE_ESPI_Data_Model.SMD_Click-Thru_1.0 (PDF, 365 KB)
   
   Supported_Data_Elements_espiDerived.SMD_Click_Thru_1.0 (PDF, 239 KB)
   
   ESPI_XSDS (ZIP, 46 KB)

December 20, 2015

Required Changes: the following SMD 2.0 updates require changes on the part of third parties.

1. In consideration of third parties with GBCMD (Green Button Connect My Data) implementations at multiple utilities besides just PG&E, we will be passing back the dataCustodianID (i.e., dataCustodianID=PGE) in the redirect to thirdPartyScopeSelectionScreenURI during the OAuth authorization sequence.
2. API requests that accept date parameters (e.g., batch request), must use Zulu data parameters (e.g., published-max/ published-min). Other date formats for the date parameters in API requests will not be supported.
   • APIs that accept date parameters are documented per the attached, Supported APIs.xlsx
3. Interval TOU indicators included with Interval metered electric usage data (as applicable, indicator of what TOU period each interval corresponds to)
   • Please reference the static Program ID Mappings detailing what each interval TOU enumeration corresponds to (e.g., 1 = Summer Peak etc.). (See attached, Supported Data Elements.xlsx)
4. The client_id as found in the dataCustodianScopeSelectionScreenURI (used for third party initiated OAuth) and provided in the Application Information Resource third parties request during Registration Testing is being updated to 5 digits if it's not already (e.g., adding leading zeros etc). In addition, the URL no longer includes '&verified=true' at the end. Third parties will need to update their URLs accordingly.
   • To elaborate, the dataCustodianScopeSelectionScreenURI looks as follows: https://sharemydataqa.pge.com/myAuthorization/?clientId=XXXX (XXXX is the clientID)
   • So a current clientID of 123 will change to something like 00123 meaning their new dataCustodianScopeSelectionScreenURI will be as follows:
     https://sharemydataqa.pge.com/myAuthorization/?clientId=00123 (old URL being as follows: https://sharemydataqa.pge.com/myAuthorization/?clientId=00123&verified=true)
5. Third parties registered as "ESP" or "Energy Service Provider" are changing to Standard User Type. There are no changes functionally, only in user type title. Distinguishing ESP user type (from Standard User type) is an un-necessary differentiation, causing confusion during the registration process without providing any differentiated functionality, hence it is being retired.

Optional Enhancements: The following changes are backwards compatible, and are voluntary enhancements third parties can elect to support.

1. Third parties will have the ability to automatically change/update their SSL certs which they originally provided during registration (e.g., when cert nears expiration) via the third party portal under manage registration >Edit > new section: SSL Certificate Information (Update option).
2. Third parties can register to receive authorized basic billing info, customer info, and gas data.  Both interval metered as well as non-interval metered customers will be eligible to authorize sharing of data for SMD 2.0. A high level summary of newly available data elements is as follows:
   • Billing Info: (for both Interval and non-interval metered SAs)
     • Rate schedule, billing $ totals, Tiered usage (as applicable), Demand (as applicable), TOU totals (as applicable)
     • Note: For authorized non-interval metered customers, third parties will only receive billing usage totals (i.e., in Usage Summary) and no interval usage reads (e.g., hourly/daily reads as they are not available)
   • Customer Info: (for both interval and non-interval metered SAs)
     • Customer Name, Service Address, Account ID, Service Agreement ID, Service Agreement service Start Date,
   • Interval Gas usage data: (interval metered gas SAs only)
     • Interval (i.e., daily) gas reads
   • New data elements are diagramed as per the attached, Supported Data Elements.xlsx
   • Associated relational data hierarchy is outlined in the attached, PGE ESPI Data Model.xlsx
   • Latest ESPI xml schema definitions (XSDs) used for these new data elements are per the attached XSDs. Note, the XSDs are backwards compatible:
     • espiDerived.xsd (Interval Usage and Billing Info)
     • retailcustomer.xsd (customer info)

Should you have any questions or need for additional support, please feel free to contact us at ShareMyData@pge.com.

December 18, 2015

Required Changes: the following SMD 2.0 updates require changes on the part of those users accessing their own data:

1. API requests that accept date parameters (e.g., batch request), must use Zulu data parameters (e.g., published-max/ published-min). Other date formats for the date parameters in API requests will not be supported.
   • APIs that accept date parameters are documented per the attached, Supported APIs.xlsx
2. Interval Time of Use (TOU) indicators included with Interval metered electric usage data (as applicable, indicator of what TOU period each interval corresponds to)
   • Please reference the static Program ID Mappings detailing what each interval TOU enumeration corresponds to (e.g., 1 = Summer Peak etc.). (See attached, Supported Data Elements.xlsx)

Optional Enhancements: The following changes are backwards compatible, and are voluntary enhancements third parties can elect to support.

1. Self Access users will have the ability to automatically change/update their SSL certs which they originally provided during registration (e.g., when cert nears expiration) via the third party portal under manage registration > Edit > new section: SSL Certificate Information (Update option)
2. Self Access user registrations will be updated to include authorized basic billing info, customer info, and gas data. Both interval metered as well as non-interval metered Service Agreements will be eligible for (self) authorization for SMD 2.0 A high level summary of newly available data elements is as follows:
   • Billing Info: (for both Interval and non-interval metered SAs)
     • Rate schedule, billing $ totals, Tiered usage (as applicable), Demand (as applicable), TOU totals (as applicable)
     • Note: For authorized non-interval metered customers, third parties will only receive billing usage totals (i.e., in Usage Summary) and no interval usage reads (e.g., hourly/daily reads as they are not available)
   • Customer Info: (for both interval and non-interval metered SAs)
     • Customer Name, Service Address, Account ID, Service Agreement ID, Service Agreement service Start Date,
   • Interval Gas usage data: (interval metered gas SAs only)
     • Interval (i.e., daily) gas reads
   • New data elements are diagramed as per the attached, Supported Data Elements.xlsx
   • Associated relational data hierarchy is outlined in the attached, PGE ESPI Data Model.xlsx
   • Latest ESPI xml schema definitions (XSDs) used for these new data elements are per the attached XSDs. Note, the XSDs are backwards compatible:
     • espiDerived.xsd (Interval Usage and Billing Info)
     • retailcustomer.xsd (customer info)

Should you have any questions or need for additional support, please feel free to contact us at ShareMyData@pge.com.

December 18, 2015

Required Changes: the following SMD 2.0 updates require changes on the part of CCA implementations.

1. Ad hoc requests (e.g., for historical data), must be made using Zulu time date parameters. Other date formats for the date parameters in API requests will not be supported.
2. The daily bulk usage feed will begin to include basic billing info while the daily bulk customer feed will include additional customer info. This new data will be provided both for interval metered customers that they receive data for currently, as well as for non-interval metered customers in their territory for which they don't receive data currently. Lastly, interval usage values provided in the daily bulk usage feed will include interval TOU indicators where applicable. High level summary of new data elements is as follows:
   • Billing Info: (for both Interval and non-interval metered SAs)
     • Rate schedule, billing $ totals, Tiered usage (as applicable), Demand (as applicable), TOU totals (as applicable)
   • (Additional) Customer Info: (for both interval and non-interval metered SAs)
     • Customer Name, Service Address, Service Agreement service Start Date, Account ID
   • Interval TOU indicators included with Interval metered electric usage data (as applicable, indicator of what TOU period each interval corresponds to)
     • Please reference the static Program ID Mappings detailing what each interval TOU enumeration corresponds to (e.g., 1 = Summer Peak etc.). (See attached, Supported Data Elements.xlsx)
   • Latest ESPI xml schema definitions (XSDs) used for these new data elements are per the attached XSDs. Note, the XSDs are backwards compatible:
     • espiDerived.xsd (Interval Usage and Billing Info)
     • retailcustomer.xsd (Customer Info)
   • New data elements are diagramed as per the attached, Supported Data Elements.xlsx
   • Associated relational data hierarchy is outlined in the attached, PGE ESPI Data Model.xlsx

Optional Enhancements: The following changes are backwards compatible, and are voluntary enhancements third parties can elect to support.

1. CCA's can make ad hoc requests for customer information at: https://api.pge.com/GreenButtonConnect/espi/1_1/Batch/BulkRetailCustomerInfo/{BulkID} (returns latest snapshot of customer info at time of request), in addition to the daily notification received.
2. CCA's will have the ability to automatically change their SSL cert which they originally provided during registration (e.g., when the cert nears expiration) via the third party portal, under manage registration > Edit > new section: SSL Certificate Information (Update option)

Should you have any questions or need for additional support, please feel free to contact us at ShareMyData@pge.com.

August 21, 2015

What's new:

1. State param and resource URI changes in Oauth responses
   • As part of the OAuth authorization code request, the third party has the option to send in a state parameter which PG&E would send back to the third party. PG&E will also send the authorization code on successful completion of authorization. This optional state param can be used to help the third party identify where the request was initiated, and to tie the request back to the authorizations they initiated.
   • As part of the successful completion of token request, we share back resourceURI and authorizationURI separately from the token information. Currently these URIs are flipped and as part of this release we will be correcting that.

Fixed defects:

1. Default dates published-max and published-min
   Currently PG&E mandates the third party sends in published-min and published-max parameters in epoch seconds for each data request to tell PG&E the duration for which they are requesting data. We are implementing a change to handle requests for the following scenarios:
   • published-min and published-max values are missing
   • published-min and published-max values are in UTC
   • published-min and published-max values are in epoch seconds
   In the event that the parameters are missing, PG&E will return default dates, as opposed to error messages as returned prior to this change. Default, in our case, is one day's data for the date T-2. If the parameters are present and formatted correctly we will continue to honor the parameters.
2. Fix for dates in authorization xml
   Currently in the authorization xml we shared the published date and authorization date. These dates are in milliseconds as opposed to seconds which is the standard. We are fixing it to be sent back in epoch seconds instead of milliseconds.
3. Incorrect XML returned for /resource/Subscription/{id}/UsagePoint/{id}/MeterReading/{id}/IntervalBlock
   Currently we are returning incorrect response for the above resource level GET where the structure of the XML is incorrect and we are repeating entries for each interval instead of creating one single interval block for a 24 hour duration.
   
   This is being fixed and only a single interval block will be returned for a 24 interval block.

Questions or concerns? Please contact ShareMyData@pge.com.